La tabla Detalle tiene que tener PK?

[ZeRoberto]

Tengo una tabla Llamado Kardex y su PK es KardexID, luego tengo una tabla detalle Kardex_Lineas y tiene un campo KardexID que se enlaza con la tabla Cajas, mi preguntas si Kardex_Lineas debe tener un PK y que campos serian.

[Alejandro Isla]

Los campos de la relaciones deben (es muy conveniente) estar indexados, pero no es necesario que sea mediante PK, es más, en tu ejemplo parecería imposible ya que estimo que kardex_lineas posee varios registros por cada kardexid.

Aparte de eso, es conveniente (si la tabla no es muy reducida) y hasta muy necesario tener un PK (simple o compuesto) en cada tabla para poder aplicar con facilidad los ABM sobre la misma.

Saludos.

[Carlos Miguel FARIAS]

Para tener un buen diseño de tablas, debes normalizar, con las especificaciones que pasas, es muy dificil normalizar, porque se debe adivinar la funcionalidad de los datos que quieres representar.

Las claves primarias deben (además de tener valores únicos) ser mínimas, o sea la menor cantidad de campos (columnas) posibles, y tienen que ser campos de datos propios de las tablas, las claves primarias especiales, solo se deben usar si indefectiblemente, el framework no te permite tener claves primarias con múltiples columnas.

Si usas índices o no, dependerá de los requerimientos de uso de las tablas y del SGBD que uses.

Saludos: Miguel, La Pampa (RA)

[mapner]

Es recomendable que toda tabla tenga su propia PK más allá de la funcionalidad en el esquema general (Cabecera, Detalle, etc..).

A la vez en las tablas detalle, o sea las que siempre van a heredar la PK de la tabla "padre" o "cabecera" se tienen la mala costumbre de hacer claves compuestas, por ejemplo

CREATE TABLE Cab (idCab integer not null, fecha date, concepto char(50),..., PRIMARY KEY(idCab))

CREATE TABLE Det (idCab integer not null, NroLinea integer not null, ... , PRIMARY KEY(idCab,NroLinea)) 

Esto si bien lo anterior es correcto, puede complicar luego la manipulación de detalle al tener varios segmentos de clave, entonces se puede hacer

CREATE TABLE Det (idDet integer not null,idCab integer not null, NroLinea integer,... , PRIMARY KEY(idDet)) 

A su vez las PK pueden ser de tipo SEMANTICAS, o sea, que tienen significado en el mundo real como por ej. Nro. de Documento o ISBN (si fuera un libro) o etc ...  o bien de tipo NO SEMANTICAS donde el valor de la clave no tiene ninguna representación del mundo real.

Por lo general es recomendable usar PKs no semánticas y si son autogeneradas por la BD mejor todavía, esto es porque las claves semánticas pueden no ser estables en el tiempo y con su posterior correción se desorganice el esquema de BD existente. 

* Saludos

El domingo, 8 de febrero de 2015, 13:46:59 (UTC-3), Ze Roberto escribió:

[Carlos Miguel FARIAS]

Estimado Mapner: La mala costumbre que indicas con referencia a las claves primarias compuestas de las tablas "detalle", no es una mala costumbre, es algo que surge de la ingeniería de diseño de base de datos. Que porque somos haraganes o burros o usamos un "framework" que no entedemos o dominamos, nos resulta difícil manejar una clave compuesta y por eso definimos una simple, es "5 guitas" aparte.

Las PKs autogeneradas solo se justifican cuando por la naturaleza de lo que estamos guardando, no tenemos una clave primaria basada en datos única apropiada.

Hay muchos casos donde una clave autogenerada es necesaria, pero no siempre.

Por ejemplo, si creo personas, la persona puede tener varios documentos, o al momento de cargarse, no disponerse del mismo, por lo que no tengo un valor univoco para identificarlo, y de ahí el uso de una clave primaria autogenerada (no digo autoincremental, porque tampoco me convence su uso, y ya he propuesto alternativas útiles).

En el caso de la persona, esta se crea y posiblemente, algún tiempo después se completa el dato del DNI (si se completa en algún momento).

Puede justificarse al crear una factura, en un entorno multiusuario, porque necesito un identificador del comprobante mientras le asigno detalle, y hasta que no se determine el momento de impresión, no puedo definir la numeración apropiada (no puedo "reservar números de factura), o en algunos sistemas, donde el cliente va comprando durante todo el mes (tipo cuenta corriente), y se le hace una única factura a fin de mes. Entonces en este caso, la factura "abierta", no tiene disponible su identificador "legal" hasta el momento del "cierre", que es cuando recién podemos darle un identificador propio.

Como indique antes, muchas veces, las limitaciones en algunos "frameworks" que no admiten claves compuestas, nos lleva a utilizar (porque también fui forzado a hacerlo) claves autogeneradas.

En fox, usar claves compuestas es molesto, porque tengo que pasar cada parte a alfanumérico y luego concatenar, entonces, entonces eso es "laborioso" al momento de acceder por clave (hay que escribir la formulita) o al crear el indice.

En un SGBD externo, solo indico en el WHERE los campos claves que componen la primaria y listo.

En la tabla detalle, debe haber una PK, porque una tabla detalle es una relación muchos a muchos entre documento (factura) y productos. Esa PK debe asegurar la unicidad de que un producto figure una sola vez dentro del documento.

Si creamos un autoincremental para el detalle (como se sugiere), debemos a su vez crear un UNIQUE para iddocumento, idproducto, o sea, forzamos por error de diseño (o limitación del framework-programador) a tener dos índices, uno que funciona como pk porque no sabemos como usar el UNIQUE como pk.

Lo que indicas sobre claves semanticas al final,

"Por lo general es recomendable usar PKs no semánticas y si son autogeneradas por la BD mejor todavía, esto es porque las claves semánticas pueden no ser estables en el tiempo y con su posterior correción se desorganice el esquema de BD existente. 

"

 solo indica errores de relevamiento o diseño (o sea "rapidito y sucio").

Si se hizo correcto el relevamiento, la bd no debería desorganizarse a posteriori, y si hay que cambiarla es porque es un nuevo requerimiento al que corresponde un nuevo relevamiento.

Saludos: Miguel, La Pampa (RA)

[Jhonny Zambrana]

Muy bien por ambos pero MIGEL, deberías expresarte en singular cuando usas el termino "haraganes", "burros", jajajajjaa feliz inicio de emana para todos..!!!

[Carlos Miguel FARIAS]

Porque en singular, vos y yo ya somos dos, o sea plural.

Y disfruta de la semana laboral, solo te quedan 5 días, (bueno, un poco menos).

[Antonio Meza]

Hola Ze Roberto

Veo que algunos compañeros no tiene claro los conceptos de Identificador único de registro y un campo código o folio y esto genera muchas confusiones y malos diseños de base de datos, pero como en todo hay sus excepciones.

Para tu caso lo recomendado es que tu tabla Kardex tengas un campo ID numérico autoincrementable que sirve para identificar el registro, relacionarlo con otras tablas y nada mas. Otro campo carácter para almacenar el numero de Kardex

Y en tu tabla detalles que llamas Kardex_Lineas igual necesitas tener un campo ID numérico autoincrementable que sirve para identificar el registro, y otro campo numérico indexado donde se guardara el valor del campo ID autoincremental de la tabla Kardex para poder hacer la relación, y ya los demás campos que necesites. algo así

Kardex

id numerico 10 Primary Key Autoincremental

kardex caracter 10 (indexarlo para búsquedas y guardarías así 0000000001 )

.....

Kardex_Lineas

id numérico 10 Primary Key Autoincremental

IdKardex numérico 10 (indexado para relacionar)

.....

Como puedes notar es una estructura muy limpia muy fácil de generar consultas SQL, se relaciona por un único campo, se puede actualizar los registros por un único campo lo que hace que sea super rápido todo.

Y el campo caracter de la tabla Kardex es donde llevaras el control de folios que te recomiendo tengas una tabla auxiliar donde lleves un contador para obtener el siguiente folio, usar MAX() en multiusuarios te puede generar duplicados es una mala practica. en cambio tener una tabla de Correlativos o una tabla auxiliar donde solo tienes un campo ID y un campo numérico que se ira sumando para obtener el valor del Kardex, te permite a demás en un futuro poder tener tener valores alfanumericos como A-0000001 etc.

Los campos ID los usuarios finales no tienen ni porque saber que existen, ya que solo sirven para identificar un registro de otro y hacer relaciones, es mal practica usarlos como codigos o folios por ejemplo para facturas, ya que son valores que se puede saltar por una transaccion que no se realizo, o usarlos en tu caso del Kardex, por ello es mejor un campo a parte y caracter porque no vas a realizar sumas con ese campo solo es para mostrar al usuario o que pueda consultar un registro a través de este.

En cuanto a los Framework que no te permiten usar campos combinados como Primary Key no es que sean malos o estén,mal diseñados, es porque siguen este principio de estructura que te comente, un caso es FoxyDB que requieres de una estructura de este tipo para que todo se haga de forma transparente, como te comento existe muy mala compresión entre lo que es un PK (primary key) y un campo código o folio.

NOTA: Pero como en todo siempre hay las excepciones.

saludos

Antonio Meza

[mapner]

Miguel,

como siempre es un placer no coincidir 100% contigo :))

El usar claves compuestas se aplica a un primer diseño que asegura unicidad pero hace que la administración posterior de la BD se vuelve engorrosa 

veamos un ejemplo usando claves compuestas y semánticas : 

Sistema de Liquidación de Sueldos 

La liquidaciones para cada empleado correspondes a un período: Año / Mes / Tipo (Normal, Especial, etc)  

Tabla -> Recibo de Sueldos Cabecera -> PK compuesta: Año +  Mes + Tipo de Liq + ID Empleado  (4 segmentos -> unicidad asegurada)

Tabla -> Recibo de Sueldos Detalle -> PK Clave compuesta: Año +  Mes + Tipo de Liq + ID Empleado (hasta aquí clave de cabecera heredada) + Cod.Concepto  (5 segmentos -> unicidad asegurada)

ahora veamos un Query de relación entre cabecera-detalle de liquidación para por ejemplo un reporte

SELECT ... FROM LiqDet d   INNER JOIN    LiqEnc e    ON     d.Anio = e.Anio and d.Mes = e.Mes = AND d.Tipo = e.Tipo AND d.EmpID = e.EmpID ...

Como se ve para cumplir la relación del JOIN se deben igualar cuatro segmentos lo cual en un sistema grande donde se tengan varios Querys e intervengan varios programadores no es algo muy práctico.

El relevamiento del modelo del "mundo real" debe luego adaptarse a cierto diseño práctico en la implementación de un sistema de BD.

y otro tema es en lo posible es no utilizar claves semánticas como PK dado que en algunos casos estas claves semánticas, como ser DNI, puedan ser corregidas posteriormente y si se usaron como relación entre tablas se desajusta todo el esquema de datos. 

 

Pero entiendo que cada uno hablamos desde nuestro criterio profesional y cada maestro con su librito y a cada uno lo que sirve y funciona. :)

Saludos!

[Carlos Miguel FARIAS]

Una cosa es un buen diseño, otra cosa es la ganas de hacerlo simple para "supuestamente" trabajar menos.

He diseñado clases de acceso a datos donde no compongo ninguna clave de acceso, simplemente, la clase, toma la definición de la tabla, y compone la consulta (ya sea para lista o para acceso individual), aparte del control de claves duplicadas y demás.

El ejemplo que das es ejemplo, donde lo que propones es una "supuesta simplificación", para una complejidad que no se si está bien analizada.

Yo también busco cosas simples, y fijate que en tu análisis, que mes año se podría simplificar con numero de liquidación (hagas las que hagas en el mes, en el año en lo que sea. En tu modelo, no podes hacer dos liquidaciones del mismo tipo en el mismo mes. 

Y la tabla cabecera se soluciona con dos campos y la otra con tres, y es un analisis que te hago al voleo.

Soy amante de lo que es KISS, y a veces un solo campo, es un KISS, que deja marca (y que va a decir el cónyuge del amante??!!!).

Saludos: Miguel, La Pampa (RA)

[mapner]

Miguel,

El ejemplo de liquidación de sueldos obviamente se simplifica con sendas PK númericas autoincrementales en cabecera y  detalle y listo el pollo. El ejemplo que he planteado lo daba para mostrar lo engorroso de tomar claves compuestas para asegurar unicidad, o sea, NO LO HAGAN EN SU CASA.

Y eso de "querer trabajar menos" yo lo llamaría intentar simplificar. :))

y para poner un poco de humor acá paso un cuento del genial Woody Allen sobre un intercambio epistolar sobre ajedrez. (veo que vamos camino a eso)

http://www.zonamoebius.com/letraviva/para-acabar-con-el-ajedrez--woody-allen

Saludos!

[Antonio Meza]

Hola Miguel!!

Noto claramente que tienes un mal concepto de lo que es un identificador de registro y lo que son claves compuestas y necesidades del usuario como son por ejemplo los folios de facturas, comentas lo siguiente:

Las PKs autogeneradas solo se justifican cuando por la naturaleza de lo que estamos guardando, no tenemos una clave primaria basada en datos única apropiada.

Los campos primary key (PK) autogenerados o autoincrementables sirven para identificar y diferenciar un registro de otro dentro de una tabla, sirven para realizar casi todas las operaciones CRUD (Crear, Obtener, Actualizar y Borrar), también para crear relaciones con otras tablas, es decir todo lo que se tiene que manejar con el servidor de base de datos se hace a través de los PK con la excepción de las consultas (select) que se requieren realizar en otros campos por requerimiento del usuario, puesto que los PK los usuarios finales no tienen porque saber que existen, ya que son solo para el uso interno de la administración de la base de datos, para lo que ya comente el CRUD y nada mas.

Luego comentas lo siguiente que remarco en negritas, y claramente afirmas que no te convence su uso, puesto que no tienes claro para que se usan. a mi me costo entenderlo y ahora no puedo vivir sin los PK autogenerados jeje

Por ejemplo, si creo personas, la persona puede tener varios documentos, o al momento de cargarse, no disponerse del mismo, por lo que no tengo un valor univoco para identificarlo, y de ahí el uso de una clave primaria autogenerada (no digo autoincremental, porque tampoco me convence su uso, y ya he propuesto alternativas útiles).

En el caso de la persona, esta se crea y posiblemente, algún tiempo después se completa el dato del DNI (si se completa en algún momento).

Claramente se ve que estas mezclando el concepto de un identificador de registro con un campo clave (puede ser llamado folio, DNI, Factura, consecutivo, etc) pero son dos cosas totalmente distintas que no se deben mezclar, y ahí creo que es lo que te genera la confusión, porque si me dices que para enviar un UPDATE a un tabla lo haces a través de un campo donde almacenas el DNI, pues tienes un mal diseño, que si funciona claro que si, pero no es lo correcto, porque estas mezclando dos entidades que tienen diferente uso, en cambio si envías un UPDATE por el campo PK, estas aplicando una buena practica, el rendimiento de la actualización sera mejor, que crees que pase si requieres modificar el campo donde guardas el DNI ? rompes toda las relaciones y estructura, en cambio si lo manejas todo a través de los PK no importa lo que hagas con el campo DNI, si lo eliminas no pasa nada, si lo agrandas o lo haces mas pequeño, porque internamente te comunicas por el PK y no por un campo X,

Luego comentas lo siguiente:

Como indique antes, muchas veces, las limitaciones en algunos "frameworks" que no admiten claves compuestas, nos lleva a utilizar (porque también fui forzado a hacerlo) claves autogeneradas.

Nuevamente denotas la mala interpretación de los campos autogenerados y su importancia, FoxtDb es una librería de acceso a datos y usa al 100% PK autogenerados, y es un requisito que todas (TODAS) las tablas tengan un campo PK autoincrementable ya que para eso fueron creados para permitirnos obtener un identificador único por registro de forma nativa generado por el propio manejador de base de datos y no tener que controlarlo por programación.

La pregunta debo usar campos PK autogenerados en todas mis tablas, mi respuesta personal es SI, y si la tabla solo tiene un registro? mi respuesta personal es SI, por que?, porque si en un futuro esa tabla que solo tiene un registro necesito tener mas registros no me interesa saber que campos voy a agregar ya que mi PK me permitirá administrar la tabla, (Agregar, insertar, eliminar) y en cambio si no use un PK y use un campo X para las operaciones y resulta que se debe modificar, pues tengo que reprogramar todo el acceso a esa tabla, sus relaciones si las tiene, etc. Me afecta tener un PK en una tabla con un registro? NO, si no me afecta y me es útil pues mejor lo uso no creen!!

Miguel, como puedes ver los campos PK autoincrementables son para el manejo interno, sin importar los campos claves, folios, códigos que los usuarios utilicen no debe haber relación directa entre ellos, son dos entidades distintas y con usos diferentes, una vez que entiendas esta diferencia amaras a los PK como yo lo hago jajajaj (que cursi me vi)

Ya que tenemos un registro identificado en la tabla por medio de nuestro PK para realizar el CRUD (a excepción de las consultas 'select'), entonces vamos a ver que necesita el usuario, si hablamos de lo mas común una Factura, el usuario te dirá que requiere un folio único por factura, entonces en tu tabla agregas un campo CARACTER para almacenar el folio de la factura, porque es otro error común en el diseño de una base de datos usar campos numéricos en valores que no se van a sumar y en tu tabla de detalles de la factura igual tendrás un PK para identificar el registro del detalle y un campo numérico para almacenar el campo PK de la tabla cabecera de facturas y poder relacionarlos, y listo tablas normalizadas y fácil control y administración. Y no olvidar una tabla auxiliar que solo manejara su campo PK y un campo numérico para ir incrementando el folio de la factura, porque si usan MAX() en multiusuario ya veré los problemas de duplicados o errores.

Pero luego te dice el usuario que ahora necesita que el sistema permita capturar facturas por sucursal, entonces agregas fácilmente un nuevo campo numérico donde guardaras el ID autonumerico de tu tabla catalogo de sucursales, y creas un indice compuesto de tu campo Sucursal + Factura para que no permitas que se duplique un folio por factura y en la tabla auxiliar agregas un campo igual numérico para guardar el Pk de la tabla catalogo de sucursales, para poder obtener el consecutivo por sucursal.

Pasados los meses ahora te dice el usuario que requiere que el sistema genere folios por periodo, es decir que cada año empiece desde CERO el consecutivo de facturas, por lo que agregas un nuevo campo caracter para el periodo y modificas tu campo combinado para que ahora sea Periodo + Sucursal + Factura. y en tu tabla auxiliar agregar el nuevo campo Perido para que puedas incrementar el consecutivo por periodo y sucursal.

Como puedes observar la relación que existe en tu tabla Factura y la tabla Factura detalle nunca se va a necesitar modificar porque no tiene nada que ver la relación de los PK con las modificaciones que te esta solicitando el usuario, ya que insto son dos identidades distintas con distintos fines. De esta manera el diseño de tu base de datos esta normalizada, una estructura muy limpia y facilita el generar las consultas (Select) y las relaciones son por un solo campo lo que genera un código limpio y una velocidad impresionante en la base de datos, a diferencia de un mal diseño como el que Mapner te comento y no le entendiste.

Ahora bien cuando el usuario necesite buscar una factura, sera necesario que le solicites el Periodo, la sucursal y el folio, claramente debes adaptar los indices y claves compuestas según la necesidad, pero internamente no tiene nada que ver con los PK autoincrementables y las relaciones de tus tablas. O que quieres buscar las facturas por cliente, en tu tabla de cabecera Facturas tienes agregado el PK autoincremental del catalogo de clientes y ya puedes hacer la relación fácilmente, si en cambio utilizas un campo consecutivo que generas manual, 001, 002, 003 y con ese relacionaste tu factura con el catalogo de clientes, pues una mala practica, mal diseño, para eso están los PK autoincrementables para facilitar el diseño y relación y muchas muchas cosas internas.

Me dirás que funciona como tu indicas y si claro que funciona, pero no es optimo, sera difícil de mantener y por ejemplo como te decía si el usuario va a consultar o modificar una factura, le solicitas el periodo, sucursal y folio, ya que lo localizaste el registro pues ya tienes el valor del PK, si el usuario modifica algo solo envías un UPDATE WHERE PK = 1 y si no usas los autoincrementables, pues ya veré tu UPDATE Where Periodo = 2015 and sucursal = '001' and Folio = '00005' 

Cual Update crees que sera mas rápido? y todo gracias a que existen los PK autoincrementables y que el mismo motor de base de datos los autogenera y solo tienes que utilizarlos para identificar y administrar los registros, y para los requerimientos de los usuarios usas claves, folios, consecutivos, combinados, mezclados, etc etc.

Espero haberme explicado aunque se que faltaron algunos detalles pero si no esto seria una biblia jejeje

Cualquier duda comentarla la analizamos y a demás sirve para los demás personas que visitan el foro vayan aprendiendo y lo que yo tenga mal interpretado si estoy equivocado pues todo lo que sea para mejorar sera bien recibido y seguir aprendiendo.

saludos

Antonio Meza

[mapner]

Lo único que agregaría es que a veces nos toca mantener sistemas "legacy" o "viejos" con esquemas para nada ideales y ahí es común encontrarse con claves primarias compuestas con varios segmentos y otras lindezas. Entonces los frameworks deberían considerar estos casos, sino estarían limitados a trabajar con cierto tipo de diseño. No siempre somos los autores originales de las BB.DD. que nos toque mantener y hay que salir al ruedo con lo que eso.

Saludos

[Antonio Meza]

Así es Mapner, como dije en mi primer comentario siempre hay sus excepciones, pero lo correcto es como comente y por ello la mayoría de los framework tiene ese diseño y si la mayoría lo tienes es por algo bueno, no creo que lo tengan solo porque funciona.

saludos

Antonio Meza

[ZeRoberto]

Entonces la respuesta es la tabla DETALLE no debe terner PK solo FK?

[Antonio Meza]

Por supuesto que debes tener un PK y a parte su FK en la tabla detalles, si les mi comentario a Miguel ahí explico porque.

Ve el siguiente vídeo, seria como usar una tabla sin tener un PK

https://www.facebook.com/video.php?v=755082664573408

Si la tabla tuviera su PK entonces vas directo al registro (llenar el pozo) y no pasar por la carretilla para después llenar el pozo.

saludos

Antonio Meza

[ZeRoberto]

Pero como estaria compuesta la PK del DETALLE

[Antonio Meza]

Veo que mencionas 3 tablas, Kardex, Kardex_Lineas y Caja, y dices lo siguiente

Kardex - PK = KardexID

Kardex_Lineas campo KardexID que se relaciona con la tabla CAJA

Porque no muestras parte de la estructura de tus tres tablas para entender que es lo que quieres hacer y darte unas ideas. ya que la tercera tabla Cajas no entiendo que relación quieres hacer.

O si pudieras explicar el resultado que necesitas tener.

saludos

Antonio Meza

[Carlos Miguel FARIAS]

Señores, hagan lo que les gusta, pero...

Alguno es ingeniero de sistemas con especialización en base de datos?

Yo no lo soy, pero he leido a expertos (y hablado con algunos) donde las claves autoincrementales o autogeneradas por el sistema, no emergente de datos son para casos especiales y no son la norma.

Y no estoy confundiendo claves, ni indices ni nada por el estilo.

Y en la bibliografía de diseño de bd, casi ni se mencionan las claves primarias no naturales (ese es el término).

Entonces, si existe posibilidad de una clave natural, hay que usarla, sea uno, dos o más campos.

Si vamos al caso, vfp no incorporó autoincrementales hasta la versión 8.

Ah, el ejemplo de lo que quiere el usuario con las facturas, que si los folios empiezan por mes o por año, son datos aparte. Y además cosas específicas de cada usuario que amerita un análisis aparte.

En cuanto al esquema o eficiencia de usar un índice simple o con múltiples campos, y tendría que ver que bien analizastes los indices. (y el SGBD que uses).

Si leen bien lo que escribi, no estoy negando totalmente el uso de pk autoincrementales, y de hecho, hay casos (no todos) que no quedan otro.

Por ejemplo, entradas en bitácora, registro de entrada de empleados, todo lo que al cargarse son eventos secuenciales (por ejemplo noticias, registro de usuarios, llegadas o salidas de algo) que no tienen claves naturales y deben recurrir a una artificial.

En fin, cada loco con su librito. Y en cuanto a la jugada del ajedrez, me tenes podrido que cada vez que jugamos ajedrez pingpong, me corras la red de casillero.

Y no era ajedrez, eran damas.

Saludos: Miguel, La Pampa (RA)

[Antonio Meza]

jajaj Miguel, casi casi me dices que es mejor hacer lo del vídeo este:

https://www.facebook.com/video.php?v=755082664573408

Como puedes ver en el vídeo al final funciona, pero fue lo mejor?

saludos
Antonio Meza