Llaves compuestas?? Cuando utilizarlas?

[Carxl]

Hola a todos, cómo van??

Mmmm es una duda técnica... tal como dice el título del mensaje... cuando utilizar llaves compuestas como pk?? La verdad no sé si nunca las he necesitado o es otra de forma de hacer una pk, como es mejor un pk como identificador numérico o utilizar varios campos como pk??

Siempre que hago una tabla, su pk es un identificador numérico autoincrementable.

Espero me hayan entendido...

Saludos

[seyko]

Iniciado por Carxl

Hola a todos, cómo van??

Mmmm es una duda técnica... tal como dice el título del mensaje... cuando utilizar llaves compuestas como pk??

Por ejemplo en relacion n:m.
Tablas Coches(PK = id_coche)-Conductores(PK = id_conductor)
Tabla n:m Conduciones (PK = id_coche, id_conductor)

La verdad no sé si nunca las he necesitado o es otra de forma de hacer una pk, como es mejor un pk como identificador numérico o utilizar varios campos como pk??

Siempre que hago una tabla, su pk es un identificador numérico autoincrementable.

Siempre que puedas hacerlo, mejor ;)

Salu2

[Carxl]

Que pena con ustedes, no fue muy claro...

Seyko, gracias por respoder; en las relaciones n:m siempre utilizo llaves compuestas Mi pregunta es fuera de esa opción, cuando es mejor utilizar compuestas como pk?? Cuando es necesario crear llaves compuestas en vez de un autonumérico?? No fuí muy claro...

Saludos, excusas de nuevo

[seyko]

Personalmente, solo las utilizo cuando no queda más remedio, y esto solo me ha pasado cuando he tocado una BD que ya existia y que habia que cambiar, como ya estaba en producción no tuve más remedio que hacerlo.

Mi opinion, es que fuera de las n:m y con un buen diseño no son necesarias, por ejemplo:

Una tabla Semestres (PK = n_año, n_semestre) -- Aqui podrias tener una PK de dos campos
Pero se pueden dejar como UNIQUE y añadir un autoincremental como PK. Para mi esta opcion es mejor, porque simplifica las relaciones de la tabla con el resto del modelo.

A ver si ahora nos entendemos

[Genetix]

Carxl
Depende del diseño. por ejemplo en un centro de estudios los IDs representan la fecha de ingreso y numero de expediente, y según las reglas de cada institución, y así se pueden dar con los libros que su Id sea un ISBN, etc.
En general se usa cuando se desea que los Ids sean descriptivos.

Espero haber entendido tu interrogante

Saludos!

[seyko]

Iniciado por Genetix

En general se usa cuando se desea que los Ids sean descriptivos.

Un resumen genial
Hago hincapié en se desea

Salu2

[Carxl]

Hola seyko, Genetix.

Sus opiniones han sido de mucha ayuda... suponía que dependía mas de la necesidad del sistema que como una regla absoluta

Gracias por aclararme esa duda

Saludos

[matanga]

Hola,

Espero no llegar muy tarde para agregar un pequeño comentario, este debate lleva tantos años como las bases de datos relacionales, natural key vs surrogate key.

Como bien se ha dicho, es un tema de gustos y diseños, hay quienes son fanaticos religiosos de las natural key (ids descriptivos) que prefieren crear una pk compuesta de n campos en vez de una primary key surrogate o auto-numerico, o secuencia, etc. Y por supuesto estan los opuestos, que aun cuando la primary key es obvia, siempre crean un campo mas llamado Id.

La realidad es que hay que evaluar cada caso en particular, dado que hay pros y contras, independientemente de la cantidad de campos que componen la primary key, por ejemplo

Una tabla de personas, donde unos de los campos es el DNI, por definicion el DNI es unico e inmutable (no cambia), un pro puede ser que me evito JOINS cuando consulto las tablas hijos, dado que ya tengo el DNI (algo parecido a desnormalizacion), y una contra puede ser que el campo DNI ocupa mas espacio que un auto-numerico, secuencia, etc.

En fin, despues de toda esta verborragia, lo que queria comentar era que las primary key compuestas son utiles cuando se prefieren las natural key sobre las surrogate key.

Saludos