Respecto a PKs

Juan Diego Bueno,

La clave primaria en este caso es compuesta POR (NodoID , ID) y no hay nada
malo en eso, al menos que el tipo de data de [NodoID] incluya muchos bytes y
que ademas el indice clustered sea por la clave primaria. Tambien puedes usar
UNIQUEIDENTIFIER con propiedad ROWGUIDCOL para indicar que es identificador
unico global, y garantizar que los valores generados en cada nodo sean
unicos. Este metodo es usado por la replicacion MERGE.

Busca en tus libros en linea por:

- UNIQUEIDENTIFIER
- ROWGUIDCOL
- NEWID()
- NEWSEQUENTIALID


AMB


"Juan Diego Bueno" wrote:

Buenas gente:

El otro día escuché que las IDs en claves primarias deberían ser
enteras para su uso con índices y que no es bueno usar varchar para
ello. Todo eso está muy bien, pero a mi se me plantea una situación en
la que no lo acabo de ver con ids exclusivamente numéricos. Se trata
de una BD distribuida que converge en un nodo central. Cada inserción
de un registro en alguno de los nodos de esta BD no se actualiza en
tiempo real en la central, sino que se transfiere mediante una
exportación. En ese caso, a mi me cuesta pensar en claves numéricas o
autonuméricas, puesto que evidentemente a cada inserción de registro
en dos nodos diferentes, le van a corresponder los mismos IDs. El
trabajo de tener que reorganizar esos IDs en la BD central, y por ende
cambiarlos de forma que no coincidan con los de los nodos me parece
que entraña mucho riesgo, a la par que me gustaría que fueran
idénticos ambos registros.

Es por ello por lo que recurro a varchars que de alguna manera
incluyen información sobre cada uno de los nodos codificada.

¿Podríais darme alguna solución alternativa o decirme si aún así es la
correcta?

Un saludo

"Alejandro Mesa" escribió en el
mensaje news:

La clave primaria en este caso es compuesta POR (NodoID , ID) y no hay
nada
malo en eso, al menos que el tipo de data de [NodoID] incluya muchos bytes
y
que ademas el indice clustered sea por la clave primaria. Tambien puedes
usar
UNIQUEIDENTIFIER con propiedad ROWGUIDCOL para indicar que es
identificador
unico global, y garantizar que los valores generados en cada nodo sean
unicos. Este metodo es usado por la replicacion MERGE.

Hola Alejandro:

No sé si te he entendido bien o no. La clave primaria en mi caso suele ser
una sóla, aunque eso sí, formada por valores únicos del nodo, pero todo
compuesto en un sólo campo. Mi duda es respecto al tipo de ese campo, que es
varchar o char y puede alcanzar los 64 bytes según la tabla, en lugar de ser
un tipo numérico. Todo viene porque he escuchado hace poco que eso es una
mala práctica en términos de normalización e incluso de rendimiento. Y lo
que explicaba en el correo es el por qué de no usar en mi caso los tipos
numéricos. Digamos que podría usar UNIQUEIDENTIFIER, pero acabo pensando que
no hay mucha diferencia en según que casos con usar varchars en los cuales
garantizo su unicidad. Me gustaría entonces que me confirmaráis si, en caso
de no poder usar ids enteras, es mejor opción usar UNIQUEIDENTIFIER antes de
recurrir a tipos char o varchar, y si es cierto que es una mala práctica
esto último en términos de normalización.

Un saludo y gracias por tu respuesta

Juan Diego Bueno www.moondance.es

Juan Diego Bueno,

No existe una solucion unica y esta dependera de otros factores como cuantas
tablas referencian esta clave primaria usando restricciones de clave foranea.
Pudieras usar una clave alterna, que en tu lugar seria una columna tipo int,
pero corres el riesgo de que ese valor se repita en mas de un nodo, por lo
que la clave alterna debe ser una clave compuesta por mas de una columna e
incluiria la identificacion del nodo y la identificacion de la fila o tupla
(NodoID, TID). Tambien puedes programar tu aplicacion o db para que cada nodo
solo pueda usar un rango especifico, po ejemplo si tenemos 5 nodos (1, 2, 3,
4, 5), pudieramos hacer que:

Nodo 1 - 1, 10,000,000
Nodo 2 - 10,000,001, 20,000,000
...

Tambien pudieras usar uniqueidentifier para generar valores unicos en cada
nodo, pero tambien necesitas saber a cual nodo corresponde cada fila cuando
estas convergen hacia una misma db. Yo personalmente usaria (NodoID, TID) y
no uniqueidentifier, porque al converger estos valores, se puede presentar un
nivel de fragmentacion alto en la tabla donde estos convergen dado la
naturaleza randomica (no se si esta palabra existe en español - trato de
decir azar). En cada instancia por separado, puedes usar la funcion
NEWSEQUENTIALID para evitar fragmentacion, ya que los valores generados de
uniqueidentifier seran secuenciales, pero esta funcion garantiza la
secuencialidad en una instancia dada y no en instancias separadas por lo que
al unirlas, se podria presentar fragmentacion.


AMB


"Juan Diego Bueno" wrote:

"Alejandro Mesa" escribió en el
mensaje news:
> La clave primaria en este caso es compuesta POR (NodoID , ID) y no hay
> nada
> malo en eso, al menos que el tipo de data de [NodoID] incluya muchos bytes
> y
> que ademas el indice clustered sea por la clave primaria. Tambien puedes
> usar
> UNIQUEIDENTIFIER con propiedad ROWGUIDCOL para indicar que es
> identificador
> unico global, y garantizar que los valores generados en cada nodo sean
> unicos. Este metodo es usado por la replicacion MERGE.

Hola Alejandro:

No sé si te he entendido bien o no. La clave primaria en mi caso suele ser
una sóla, aunque eso sí, formada por valores únicos del nodo, pero todo
compuesto en un sólo campo. Mi duda es respecto al tipo de ese campo, que es
varchar o char y puede alcanzar los 64 bytes según la tabla, en lugar de ser
un tipo numérico. Todo viene porque he escuchado hace poco que eso es una
mala práctica en términos de normalización e incluso de rendimiento. Y lo
que explicaba en el correo es el por qué de no usar en mi caso los tipos
numéricos. Digamos que podría usar UNIQUEIDENTIFIER, pero acabo pensando que
no hay mucha diferencia en según que casos con usar varchars en los cuales
garantizo su unicidad. Me gustaría entonces que me confirmaráis si, en caso
de no poder usar ids enteras, es mejor opción usar UNIQUEIDENTIFIER antes de
recurrir a tipos char o varchar, y si es cierto que es una mala práctica
esto último en términos de normalización.

Un saludo y gracias por tu respuesta

Juan Diego Bueno www.moondance.es

Hola Juan Diego,

On Sat, 29 Mar 2008 05:10:42 -0700 (PDT), Juan Diego Bueno
wrote:

El otro día escuché que las IDs en claves primarias deberían ser
enteras para su uso con índices y que no es bueno usar varchar para
ello.

Pues yo pocas veces uso enteros en las claves, la mayoría de las veces
uso varchars por que los identificadores de mis entidades suelen ser
alfanuméricos.

Todo eso está muy bien,

Pues a mi me parece que está bastante mal. Los enteros suelen ser unos
identificadores bastante malos para los seres humanos.

pero a mi se me plantea una situación en
la que no lo acabo de ver con ids exclusivamente numéricos. Se trata
de una BD distribuida que converge en un nodo central. Cada inserción
de un registro en alguno de los nodos de esta BD no se actualiza en
tiempo real en la central, sino que se transfiere mediante una
exportación. En ese caso, a mi me cuesta pensar en claves numéricas o
autonuméricas, puesto que evidentemente a cada inserción de registro
en dos nodos diferentes, le van a corresponder los mismos IDs.

Con lo fácil que es que cada nodo tenga un identificador y usar una
clave compuesta.

Es por ello por lo que recurro a varchars que de alguna manera
incluyen información sobre cada uno de los nodos codificada.

Esto es una muy mala práctica y una violación del principio de
información de Codd. Lo correcto es usar claves compuestas aunque sean
numéricas.


Saludos
Alfredo

Hola Alfredo:

Alfredo Novoa ha acertado a formular la pregunta:

Hola Juan Diego,

On Sat, 29 Mar 2008 05:10:42 -0700 (PDT), Juan Diego Bueno
wrote:

El otro día escuché que las IDs en claves primarias deberían ser
enteras para su uso con índices y que no es bueno usar varchar para
ello.

Pues yo pocas veces uso enteros en las claves, la mayoría de las veces
uso varchars por que los identificadores de mis entidades suelen ser
alfanuméricos.

Todo eso está muy bien,

Pues a mi me parece que está bastante mal. Los enteros suelen ser unos
identificadores bastante malos para los seres humanos.

Bueno, al menos en eso no lo estoy haciendo mal.

pero a mi se me plantea una situación en
la que no lo acabo de ver con ids exclusivamente numéricos. Se trata
de una BD distribuida que converge en un nodo central. Cada inserción
de un registro en alguno de los nodos de esta BD no se actualiza en
tiempo real en la central, sino que se transfiere mediante una
exportación. En ese caso, a mi me cuesta pensar en claves numéricas o
autonuméricas, puesto que evidentemente a cada inserción de registro
en dos nodos diferentes, le van a corresponder los mismos IDs.

Con lo fácil que es que cada nodo tenga un identificador y usar una
clave compuesta.

Es por ello por lo que recurro a varchars que de alguna manera
incluyen información sobre cada uno de los nodos codificada.

Esto es una muy mala práctica y una violación del principio de
información de Codd. Lo correcto es usar claves compuestas aunque sean
numéricas.

Es decir, tu propones al igual que Alejandro, una clave primaria
compuesta por dos campos: NodoID, ID ¿pero no es un coñazo esto en
términos de claves foráneas?. Si yo hago referencia en otra tabla al
registro x, tengo que establecer una clave foránea doble para esto y me
parece un jaleo considerable. Si mi nodo tiene un código sencillo, por
ejemplo, EB, no veo que hay de malo en que yo a un id de pedido le
llame EB-100 y lo contenga en una sola clave. Me gustaría saber por qué
esto rompe dicho principio de información de Codd (no porque no lo
cuestione, sino porque no tengo muy claro en que consiste)

Un saludo

http://www.moondance.tk