Claves naturales o artificiales ?, Una cuestion de diseño.

Echa un vistazo a este artículo
http://www.configuracionesintegrale...iales.asp?
articulo!9


Un saludo

-
"Sólo sé que no sé nada. " (Sócrates)

"Jose Luis" escribió en el mensaje
news:#

Un saludo a todos

Tengo un programa de produccion y facturacion que estoy pasando de

ficheros

isam a mssql, ademas quiero aprovechar el cambio para introducir algunas
mejoras, la mas importante de ellas referente a la gestion de temporadas,

me

explico:

La base de datos tiene una serie de tablas ( actualmente mas de 60 ) para
gestionar pedidos, facturas, articulos, control de produccion, etc,. Los
articulos, los pedidos de estos y su produccion y entrega vienen

organizados

en temporadas por lo que debo introducir este nuevo dato en la base de

datos

y aqui viene el problema.

Hasta ahora mis claves primarias eran las claves naturales de cada tabla,
Atrticulos: CodArticulo, Pedidos: CodPedido, etc.

Con la introduccion de temporadas todo se complica ya que las claves
naturales pasan a ser compuestas, Articulos: CodTemporada+Codarticulo,
Pedidos: CodTemporada+CodPedido, etc, y debo arrastrar estas claves
compuestas a lo largo de toda la aplicacion. por ejemplo en una Lineas de
pedido debo leer un CodArticulo, pero validarlo solo en los articulos de

la

Temporada del pedido, etc.

O utilizo claves artificiales incluyendo un campo identity en cada tabla

del

tipo NombreTablaID como clave primaria y lo uso en toda la RI de la
aplicacion, aunque esto me obligaria a gestionar dos claves para cada

tabla,

una artificial (ID) para enlace con otras tablas y una natural para acceso
de los usuarios a los datos,

Cada solucion tiene sus pros y contras pero una vez me decida por un

camino

seria muy dificil volver atras.
Por regla general que metodo es el mas usado.?
Algun consejo o comentario?

Gracias.

Hola

Dos preguntas pues no entendi algunas cosas del articulo:

1) Cuando uno tiene una clave artificial tipo identity como clave primaria,
es conveniente o perjudicial que sea CLUSTERED ?
Sobre todo considerando que se van a estar borrando (delete) registros de la
tabla.

2) El ahorro de espacio/eficiencia que se obtenga de reemplazar todas las
claves primarias naturales por artificiales no implicaria que la natural
seguiria existiendo y ocupando mayor espacio de por si tendriamos que tener
indices adicionales para la clave natural pues es normal ordenar los
resultados por estas claves ? Lo que quiero decir es que lo que se pueda
ganar en eficiencia por un lado, se degrada por el otro ?

Gracias



"Carlos Sacristán" <csacristanARROBAmvpsPUNTOorg> wrote in message
news:%

Echa un vistazo a este artículo

http://www.configuracionesintegrale...iales.asp?

articulo!9


Un saludo

-
"Sólo sé que no sé nada. " (Sócrates)

"Jose Luis" escribió en el mensaje
news:#
> Un saludo a todos
>
> Tengo un programa de produccion y facturacion que estoy pasando de
ficheros
> isam a mssql, ademas quiero aprovechar el cambio para introducir algunas
> mejoras, la mas importante de ellas referente a la gestion de

temporadas,

me
> explico:
>
> La base de datos tiene una serie de tablas ( actualmente mas de 60 )

para

> gestionar pedidos, facturas, articulos, control de produccion, etc,. Los
> articulos, los pedidos de estos y su produccion y entrega vienen
organizados
> en temporadas por lo que debo introducir este nuevo dato en la base de
datos
> y aqui viene el problema.
>
> Hasta ahora mis claves primarias eran las claves naturales de cada

tabla,

> Atrticulos: CodArticulo, Pedidos: CodPedido, etc.
>
> Con la introduccion de temporadas todo se complica ya que las claves
> naturales pasan a ser compuestas, Articulos: CodTemporada+Codarticulo,
> Pedidos: CodTemporada+CodPedido, etc, y debo arrastrar estas claves
> compuestas a lo largo de toda la aplicacion. por ejemplo en una Lineas

de

> pedido debo leer un CodArticulo, pero validarlo solo en los articulos de
la
> Temporada del pedido, etc.
>
> O utilizo claves artificiales incluyendo un campo identity en cada tabla
del
> tipo NombreTablaID como clave primaria y lo uso en toda la RI de la
> aplicacion, aunque esto me obligaria a gestionar dos claves para cada
tabla,
> una artificial (ID) para enlace con otras tablas y una natural para

acceso

> de los usuarios a los datos,
>
> Cada solucion tiene sus pros y contras pero una vez me decida por un
camino
> seria muy dificil volver atras.
> Por regla general que metodo es el mas usado.?
> Algun consejo o comentario?
>
> Gracias.
>
>
>

Respuestas en línea...


Un saludo

-
"Sólo sé que no sé nada. " (Sócrates)

"El principiante" escribió en el mensaje
news:

Hola

Dos preguntas pues no entendi algunas cosas del articulo:

1) Cuando uno tiene una clave artificial tipo identity como clave

primaria,

es conveniente o perjudicial que sea CLUSTERED ?
Sobre todo considerando que se van a estar borrando (delete) registros de

la

tabla.

ser más eficiente un índice no agrupado (non clustered), pero todo es
cuestión de efectuar pruebas de rendimiento en tu entorno

2) El ahorro de espacio/eficiencia que se obtenga de reemplazar todas las
claves primarias naturales por artificiales no implicaria que la natural
seguiria existiendo y ocupando mayor espacio de por si tendriamos que

tener

indices adicionales para la clave natural pues es normal ordenar los
resultados por estas claves ? Lo que quiero decir es que lo que se pueda
ganar en eficiencia por un lado, se degrada por el otro ?

la ventaja de tener una clave artificial pequeña no compensa porque luego el
uso que se va a hacer de los datos implican otro diseño

Gracias



"Carlos Sacristán" <csacristanARROBAmvpsPUNTOorg> wrote in message
news:%
> Echa un vistazo a este artículo
>

http://www.configuracionesintegrale...iales.asp?

> articulo!9
>
>
> Un saludo
>
> -
> "Sólo sé que no sé nada. " (Sócrates)
>
> "Jose Luis" escribió en el mensaje
> news:#
> > Un saludo a todos
> >
> > Tengo un programa de produccion y facturacion que estoy pasando de
> ficheros
> > isam a mssql, ademas quiero aprovechar el cambio para introducir

algunas

> > mejoras, la mas importante de ellas referente a la gestion de
temporadas,
> me
> > explico:
> >
> > La base de datos tiene una serie de tablas ( actualmente mas de 60 )
para
> > gestionar pedidos, facturas, articulos, control de produccion, etc,.

Los

> > articulos, los pedidos de estos y su produccion y entrega vienen
> organizados
> > en temporadas por lo que debo introducir este nuevo dato en la base de
> datos
> > y aqui viene el problema.
> >
> > Hasta ahora mis claves primarias eran las claves naturales de cada
tabla,
> > Atrticulos: CodArticulo, Pedidos: CodPedido, etc.
> >
> > Con la introduccion de temporadas todo se complica ya que las claves
> > naturales pasan a ser compuestas, Articulos: CodTemporada+Codarticulo,
> > Pedidos: CodTemporada+CodPedido, etc, y debo arrastrar estas claves
> > compuestas a lo largo de toda la aplicacion. por ejemplo en una Lineas
de
> > pedido debo leer un CodArticulo, pero validarlo solo en los articulos

de

> la
> > Temporada del pedido, etc.
> >
> > O utilizo claves artificiales incluyendo un campo identity en cada

tabla

> del
> > tipo NombreTablaID como clave primaria y lo uso en toda la RI de la
> > aplicacion, aunque esto me obligaria a gestionar dos claves para cada
> tabla,
> > una artificial (ID) para enlace con otras tablas y una natural para
acceso
> > de los usuarios a los datos,
> >
> > Cada solucion tiene sus pros y contras pero una vez me decida por un
> camino
> > seria muy dificil volver atras.
> > Por regla general que metodo es el mas usado.?
> > Algun consejo o comentario?
> >
> > Gracias.
> >
> >
> >
>
>

Hola:
Mi opinion:
1.a) La llave artificial CLUSTERED suelen ser perjudiciales para el
desempeno de la tabla sobre la que se crea la llave. Porque se agregan datos
y porque si se hacen busquedas sobre la llave primaria (que es frecuente)
debe buscarse un indice de la llave primaria y luego sobre la artificial.
1.b) La llave artificial CLUSTERED suele beneficiar a los otros indices, ya
que con frecuencia es mas pequena, que la llave primaria natural por lo que
los indices no-clustered se benefician.
1.c) Lla llave artificial CLUSTERED tiene efectos mixtos sobre las otras
tablas que referencian esta tabla, por un lado la referencia es mas pequena
y por otro se requieren JOINS mas complejos cuando hay multiples tablas y la
llave natural es compuesta.
2) La llave natural debe siempre existir (con su respectivo indice) si
queremos mantener la integridad, lo cual per
Mi experiencia:
En tablas con pocas filas (menos de 100,000) o cuando la llave natural
es pequena (menos de 20 bytes), suele perjudicarse el desempeno, cuando hay
muchos filas o la llave natural es grande los beneficios en desempeno de
llaves artificiales son importantes en SQL 2000, por la forma en que se
maneja el indice.
La ventaja mas importante de las llaves artificiales no esta en el
desempeno, sino que permiten hacer 2 cosas que en la actualidad se valoran
mucho:
a) No se requiere identificar las llaves naturales. Se puede empezar a
escribir codigo mas rapido.
b) Pueden usarse las tablas como matrices, numerando las filas, haciendo
algunas cosas que son muy dificiles de lograr de otra forma.
Las desventajas mas importantes:
a) Perdida de integridad
b) Perdida del modelo mental de SQL (Teoria de Conjuntos).
En desempeno los resultados son mezclados.
Saludos,


Javier Loria
Costa Rica
Se aprecia la inclusion de DDL (CREATE, INSERTS, etc.)
que pueda ser copiado y pegado al Query Analizer.
La version de SQL y Service Pack tambien ayuda

"El principiante" wrote in message
news:

Hola

Dos preguntas pues no entendi algunas cosas del articulo:

1) Cuando uno tiene una clave artificial tipo identity como clave

primaria,

es conveniente o perjudicial que sea CLUSTERED ?
Sobre todo considerando que se van a estar borrando (delete) registros de

la

tabla.

2) El ahorro de espacio/eficiencia que se obtenga de reemplazar todas las
claves primarias naturales por artificiales no implicaria que la natural
seguiria existiendo y ocupando mayor espacio de por si tendriamos que

tener

indices adicionales para la clave natural pues es normal ordenar los
resultados por estas claves ? Lo que quiero decir es que lo que se pueda
ganar en eficiencia por un lado, se degrada por el otro ?

Gracias



"Carlos Sacristán" <csacristanARROBAmvpsPUNTOorg> wrote in message
news:%
> Echa un vistazo a este artículo
>

http://www.configuracionesintegrale...iales.asp?

> articulo!9
>
>
> Un saludo
>
> -
> "Sólo sé que no sé nada. " (Sócrates)
>
> "Jose Luis" escribió en el mensaje
> news:#
> > Un saludo a todos
> >
> > Tengo un programa de produccion y facturacion que estoy pasando de
> ficheros
> > isam a mssql, ademas quiero aprovechar el cambio para introducir

algunas

> > mejoras, la mas importante de ellas referente a la gestion de
temporadas,
> me
> > explico:
> >
> > La base de datos tiene una serie de tablas ( actualmente mas de 60 )
para
> > gestionar pedidos, facturas, articulos, control de produccion, etc,.

Los

> > articulos, los pedidos de estos y su produccion y entrega vienen
> organizados
> > en temporadas por lo que debo introducir este nuevo dato en la base de
> datos
> > y aqui viene el problema.
> >
> > Hasta ahora mis claves primarias eran las claves naturales de cada
tabla,
> > Atrticulos: CodArticulo, Pedidos: CodPedido, etc.
> >
> > Con la introduccion de temporadas todo se complica ya que las claves
> > naturales pasan a ser compuestas, Articulos: CodTemporada+Codarticulo,
> > Pedidos: CodTemporada+CodPedido, etc, y debo arrastrar estas claves
> > compuestas a lo largo de toda la aplicacion. por ejemplo en una Lineas
de
> > pedido debo leer un CodArticulo, pero validarlo solo en los articulos

de

> la
> > Temporada del pedido, etc.
> >
> > O utilizo claves artificiales incluyendo un campo identity en cada

tabla

> del
> > tipo NombreTablaID como clave primaria y lo uso en toda la RI de la
> > aplicacion, aunque esto me obligaria a gestionar dos claves para cada
> tabla,
> > una artificial (ID) para enlace con otras tablas y una natural para
acceso
> > de los usuarios a los datos,
> >
> > Cada solucion tiene sus pros y contras pero una vez me decida por un
> camino
> > seria muy dificil volver atras.
> > Por regla general que metodo es el mas usado.?
> > Algun consejo o comentario?
> >
> > Gracias.
> >
> >
> >
>
>

Mira este es un tema polemico. ojo: No debe confundirse claves
artificiales con identities, lo de "artificial" es un concepto.
En una lista de articulos de detalle de una factura, cual consideras es la
"clave natural" ? numerofactura, numerorenglon no ? que sería
"numerorenglon" ? natural o artificial ?

Para mi en general es preferible evitar las claves artificiales porque
complican los queries y hacen incomodo el manejo de la integridad
referencial (para mi algo vital, no se para otros). Pero hay casos como en
el ejemplo previo puede perfectamente usarse un identity para identificar
el renglon DENTRO de la factura. Ahora bien si se modifica una factura (o
en general un documento header-detail modificables frecuentemente) lo mas
probable es que los registros detalle se borren primero y luego se inserten
como nuevos, para esto no conviene que esta PK sea clustered pues se
volveran a generar nuevos valores para el identity y no tendras
necesariamente con mayor probabilidad en la misma página todos los registros
detalle de una misma factura. Por eso probablemente es preferible numerar
el renglon desde la aplicacion y postearlo "lleno" asi al servidor sin usar
un identity. Pero es discutible decir que "numerorenglon" como identity es
una clave artificial porque el renglon tiene conceptualmente un
identificador natural de por sí. Que se decida que sea o no sea una
secuencia estricta ya es otra cosa. No se si me explico.

No hay que ser dogmático ni muy estricto pero este caso es en el unico que
yo soporto usar un identity, aun siendo todavía innecesario. En el resto de
las cosas uso las claves naturales ojo: tratando de que estas sean lo mas
cortas posibles. Eso es importante. Hasta ahora no he visto problemas de
rendimiento relacionados con joins y similares ni siquiera en tablas de
muchos registros. El beneficio de poner en cada tabla un identity (o una
clave artificial para generalizar el concepto) yo no creo que justifique la
perdida de organizacion de integridad de la base de datos y la perdida de la
claridad en la representación de la realidad que es en definitiva un diseño.



Ricardo Passians

"El principiante" wrote in message
news:

Hola

Dos preguntas pues no entendi algunas cosas del articulo:

1) Cuando uno tiene una clave artificial tipo identity como clave

primaria,

es conveniente o perjudicial que sea CLUSTERED ?
Sobre todo considerando que se van a estar borrando (delete) registros de

la

tabla.

2) El ahorro de espacio/eficiencia que se obtenga de reemplazar todas las
claves primarias naturales por artificiales no implicaria que la natural
seguiria existiendo y ocupando mayor espacio de por si tendriamos que

tener

indices adicionales para la clave natural pues es normal ordenar los
resultados por estas claves ? Lo que quiero decir es que lo que se pueda
ganar en eficiencia por un lado, se degrada por el otro ?

Gracias



"Carlos Sacristán" <csacristanARROBAmvpsPUNTOorg> wrote in message
news:%
> Echa un vistazo a este artículo
>

http://www.configuracionesintegrale...iales.asp?

> articulo!9
>
>
> Un saludo
>
> -
> "Sólo sé que no sé nada. " (Sócrates)
>
> "Jose Luis" escribió en el mensaje
> news:#
> > Un saludo a todos
> >
> > Tengo un programa de produccion y facturacion que estoy pasando de
> ficheros
> > isam a mssql, ademas quiero aprovechar el cambio para introducir

algunas

> > mejoras, la mas importante de ellas referente a la gestion de
temporadas,
> me
> > explico:
> >
> > La base de datos tiene una serie de tablas ( actualmente mas de 60 )
para
> > gestionar pedidos, facturas, articulos, control de produccion, etc,.

Los

> > articulos, los pedidos de estos y su produccion y entrega vienen
> organizados
> > en temporadas por lo que debo introducir este nuevo dato en la base de
> datos
> > y aqui viene el problema.
> >
> > Hasta ahora mis claves primarias eran las claves naturales de cada
tabla,
> > Atrticulos: CodArticulo, Pedidos: CodPedido, etc.
> >
> > Con la introduccion de temporadas todo se complica ya que las claves
> > naturales pasan a ser compuestas, Articulos: CodTemporada+Codarticulo,
> > Pedidos: CodTemporada+CodPedido, etc, y debo arrastrar estas claves
> > compuestas a lo largo de toda la aplicacion. por ejemplo en una Lineas
de
> > pedido debo leer un CodArticulo, pero validarlo solo en los articulos

de

> la
> > Temporada del pedido, etc.
> >
> > O utilizo claves artificiales incluyendo un campo identity en cada

tabla

> del
> > tipo NombreTablaID como clave primaria y lo uso en toda la RI de la
> > aplicacion, aunque esto me obligaria a gestionar dos claves para cada
> tabla,
> > una artificial (ID) para enlace con otras tablas y una natural para
acceso
> > de los usuarios a los datos,
> >
> > Cada solucion tiene sus pros y contras pero una vez me decida por un
> camino
> > seria muy dificil volver atras.
> > Por regla general que metodo es el mas usado.?
> > Algun consejo o comentario?
> >
> > Gracias.
> >
> >
> >
>
>