OT: Claves primarias naturales o subrogadas?
326 views
Skip to first unread message
Antonio Meza
Feb 9, 2015, 7:19:21 PM2/9/15
to publice...@googlegroups.com
Diseñar una base de datos no es solo agregar campos e indices, y mas allá de muchos aspectos como definir el tipo de campo, muchos desconocen la importancia de las llaves primarias o claves primarias (PK)
Como programe en Dbase, Clipper y VFP pues siempre use DBF y utilice claves naturales, al pasar el tiempo el administrar la base de datos (DBC) y el propio desarrollo se me fue complicando mucho ya que agregar un simple campo que debería ser compuesto me generaba rediseñar la base de datos así como el desarrollo.
Cuando comencé a diseñar FoxyDb (DbVfp), investigue mucho sobre este tema, si usar claves Naturales (DNI, Factura, Código Postal) o usar claves autogeneradas numéricas. Las 6 razones fundamentales que me llevo a tomar la decisión de utilizar PK Autoincrementables (subrogadas) fueron:
1.- No depender del Usuario para que indicara este valor
2.- No tuviera ninguna relación con otros campo de la tabla
3.- Que fuera lo mas optimizable para las relaciones (Join)
4.- No se viera afectado por nuevos requerimientos futuros.
5.- Seria de uso interno y el usuario no tenga que saber que existe.
6.- Que se generara de forma automática sin importar la aplicación.
Por lo tanto usar claves naturales no cumplía con ninguno de estos puntos, y me tomo tiempo entenderlo, leer muchos debates sobre el tema, y al final decidirme por las claves primarias autogeneradas.
La pregunta es que usan ustedes?, si van a cambiar de DBF a un servidor de base de datos es muy importante estudiar este punto.
Les recomiendo el siguiente articulo, vale la pena leerlo completo hasta los comentarios, como en todo a veces mal interpretamos algo y damos por hecho que así es mejor y cuesta mucho el cambio, a mi me costo mucho cambiar mi forma de pensar al pasarme a una servidor de base de datos, espero y les pueda servir.
y les paso el siguiente vídeo para que se rían un rato, pero mas que reír a veces nosotros como programadores terminamos haciendo eso mismo que vemos en el vídeo, ya sea por costumbre, porque así lo entendimos, o lo mas fácil porque funciona, pero no siempre por el hecho de que funcione es lo mejor.
saludos
Antonio Meza
mapner
Feb 9, 2015, 7:43:22 PM2/9/15
to publice...@googlegroups.com
Los motores de bd relacionales por lo general son muy potentes y versátiles pero ninguno de ellos obliga un criterio determinado a la hora de elegir que tipo de PK utilizar, por eso se puede hablar de recomendaciones pero se tiene cierta libertad para adaptarse a casos particulares. Si es verdad que hoy en día lo recomendable son PK auto incrementales no semánticas pero reitero que mucha bd que funciona por ahí proviene de sistemas legacy y los SGBD los soportan sin problema. Porque tuvieron auge en algún momento las pk basadas en claves reales simples o compuestas? La razón es que hace tiempo el almacenamiento era muy caro y todo byte de más en el diseño de registro contaba y una PK interna sin significado ocupaba lugar. Hoy en día con lo barato que es el storage eso ni se considera. Muchos "vicios" de diseño y programación vienen de esas viejas épocas.
Saludos
Saludos
Marcos Godoy
Feb 9, 2015, 8:54:01 PM2/9/15
to publice...@googlegroups.com
Coincido con Mauricio, y agrego lo siguiente, el viejo fox no admitia autoincrementales, por lo tanto también era importante conseguir una prima key biunivoca. pero una primary key autoincremental en realidad es fabulosa, ya que es el adn de cada registro, no puede haber otra...., y si borras el registro, sigue siendo unica y no vuelve a ser utilizada nunca..., con lo que posee la trazabilidad perfecta..., más ahora que todos los sistemas empiezan a necesitar certificaciones y trazabilidad de sus procesos......
Saludos
mpulla
Feb 13, 2015, 5:42:47 PM2/13/15
to publice...@googlegroups.com
Hola Foxeros.
Cuando hablamos de llaves subrogadas, siempre se habla de enteros autoincrementales, pero los SGDB como Sql Server, PostgreSql y Oracle, avanzan y nos dan nuevas herramientas con los objetos sequence que tienen la misma funcion que el entero Autoincrementales pero que nos dan un control total, lo que le da un plus sobre los enteros autoincrementales.
Por otro lado lo que comenta mapner, es verdad que el storage es barato, pero tener unos cuantos bytes demás sobre una tabla de grande te pesa en el rendimiento, mientras más compacto se tu indice mayor número de paginas almacenas en memoría por lo que te daría un mejor perform, diras la memoria tambien es barata, pero imagina cientos de tablas grandes, medianas y pequeñas todas con con 3 y 4 indices, unos cuantos bytes demás ya el servidor tendra una sobre carga, que podemos evitar escogiendo bien nuestros indices.
Respecto PK naturales o subrrogadas, prefiero subrrogadas por las razones ya comentadas por ustedes.
Saldos.
Mauricio
Cuando hablamos de llaves subrogadas, siempre se habla de enteros autoincrementales, pero los SGDB como Sql Server, PostgreSql y Oracle, avanzan y nos dan nuevas herramientas con los objetos sequence que tienen la misma funcion que el entero Autoincrementales pero que nos dan un control total, lo que le da un plus sobre los enteros autoincrementales.
Por otro lado lo que comenta mapner, es verdad que el storage es barato, pero tener unos cuantos bytes demás sobre una tabla de grande te pesa en el rendimiento, mientras más compacto se tu indice mayor número de paginas almacenas en memoría por lo que te daría un mejor perform, diras la memoria tambien es barata, pero imagina cientos de tablas grandes, medianas y pequeñas todas con con 3 y 4 indices, unos cuantos bytes demás ya el servidor tendra una sobre carga, que podemos evitar escogiendo bien nuestros indices.
Respecto PK naturales o subrrogadas, prefiero subrrogadas por las razones ya comentadas por ustedes.
Saldos.
Mauricio
Antonio Meza
Feb 13, 2015, 6:15:49 PM2/13/15
to publice...@googlegroups.com
Hola Mauricio!!
En el caso de Firebird tiene años que los maneja, solo que se llama Generadores.
Pero creo que es mejor seguir usando los campos autoincrementables como bien comentas.
En el siguiente articulo de Microsoft referente a Sql Server 2012, menciona algo muy importante que el usar estos códigos tienes que realizar muchas validaciones que te evitas al usar los campos autoincrementables, y también habla de los escenarios donde se pueden usar, pero en definitiva no serian una buena opción para remplazar a los PK.
traducción
Antonio Meza
Reply all
Reply to author
Forward
0 new messages