sql - vertabelo - ¿Qué debería considerar al seleccionar un tipo de datos para mi clave principal?

sqldb design (16)

Cuando estoy creando una nueva tabla de base de datos, ¿qué factores debo tener en cuenta para seleccionar el tipo de datos de la clave principal?

A menos que tenga una clave natural ultra conveniente disponible, utilice siempre una clave sintética (aludida) de tipo numérico. Incluso si tiene una clave natural disponible, es posible que desee considerar el uso de una clave sintética de todos modos y colocar un índice único adicional en su clave natural. Considere lo que sucedió con las bases de datos de mayor jerarquía que usaban números de seguridad social como PK cuando cambiaba la ley federal, los costos de cambiar a claves sintéticas eran enormes.

Además, tengo que estar en desacuerdo con la práctica de nombrar cada tecla principal de la misma manera, por ejemplo, "id". Esto hace que las consultas sean más difíciles de entender, no más fáciles. Las claves primarias deben nombrarse después de la tabla. Por ejemplo employee.employee_id, affiliate.affiliate_id, user.user_id, y así sucesivamente.

En la mayoría de los casos, uso una clave primaria identity int, a menos que el escenario requiera mucha replicación, en cuyo caso puedo optar por un GUID.

Yo (casi) nunca usé llaves significativas.

Los números que tienen un significado en el mundo real generalmente son una mala idea, porque de vez en cuando el mundo real cambia las reglas sobre cómo se usan esos números, en particular para permitir duplicados, y entonces usted tiene un verdadero lío en sus manos.

Me gusta usar una clave entera generada. Si espera que la base de datos crezca demasiado, puede ir con bigint.

A algunas personas les gusta usar guids. El profesional es que puede fusionar varias instancias de la base de datos sin alterar ninguna clave, pero la desventaja es que el rendimiento puede verse afectado.

No utilice un tipo numérico de coma flotante, ya que los números de punto flotante no se pueden comparar correctamente para la igualdad.

Normalmente siempre uso un número entero, pero aquí hay una perspectiva interesante.

http://www.codinghorror.com/blog/archives/000817.html

Para una clave "natural", cualquiera que sea el tipo de datos que se adapte a la (s) columna (s). Las claves artificiales (sustitutas) suelen ser números enteros.

Realmente no me gusta lo que enseñan en la escuela, es decir, usar una ''clave natural'' (por ejemplo, ISBN en una base de datos de libros) o incluso tener una clave principal compuesta de 2 o más campos. Nunca haria eso. Así que aquí está mi pequeño consejo:

Siempre tenga una columna dedicada en cada tabla para su clave principal.
Todos deben tener el mismo nombre de colomn en todas las tablas, es decir, "ID" o "GUID"
Use GUID cuando pueda (si no necesita rendimiento), de lo contrario, incrementando las INT

EDITAR:
De acuerdo, creo que necesito explicar mis elecciones un poco.

Tener un nombre de columna dedicado igual en toda la tabla para su clave principal, simplemente hace que sus declaraciones SQL sean mucho más fáciles de construir y más fáciles de entender para otra persona (que pueda no estar familiarizada con el diseño de su base de datos). Especialmente cuando haces muchas UNIDAS y cosas por el estilo. No necesita buscar cuál es la clave primaria para una tabla específica, ya lo sabe, porque es igual en todas partes.
GUIDs vs. INTs realmente no importa tanto la mayoría del tiempo. A menos que alcance el límite de rendimiento de los GUID o fusiones de bases de datos, no tendrá problemas importantes con uno u otro. PERO hay una razón por la que prefiero los GUID. La singularidad global de los GUID siempre puede ser útil algún día. Tal vez no ve la necesidad ahora, pero cosas como sincronizar partes de la base de datos con una computadora portátil o un teléfono celular o incluso encontrar registros de datos sin necesidad de saber en qué tabla se encuentran, son excelentes ejemplos de las ventajas que los GUID pueden ofrecer. proporcionar. Un entero solo identifica un registro dentro del contexto de una tabla, mientras que un GUID identifica un registro en todas partes.

Si usa una clave numérica, asegúrese de que el tipo de datos giong sea lo suficientemente grande como para contener el número de filas que podría esperar que crezca la tabla.

Si usa un GUID, ¿se debe considerar el espacio adicional necesario para almacenar el GUID? La codificación de Guid PKs será un problema para los desarrolladores o usuarios de la aplicación.

Si usa claves compuestas, ¿está seguro de que las columnas combinadas siempre serán únicas?

Siempre que sea posible, intente utilizar una clave principal que sea una clave natural. Por ejemplo, si tuviera una tabla donde registrara un registro todos los días, la fecha de inicio de sesión sería una buena clave principal. De lo contrario, si no hay una clave natural, simplemente use int. Si cree que usará más de 2 mil millones de filas, use un bigint. A algunas personas les gusta usar GUID, que funciona bien, ya que son únicas, y nunca se quedará sin espacio. Sin embargo, son innecesariamente largos y difíciles de escribir si solo está haciendo consultas ad hoc.

Todo depende.

a) ¿Está bien tener números numéricos secuenciales únicos como clave principal? Si es así, entonces seleccionar UniqueIdentifier como su clave principal será suficiente. b) Si la demanda de su negocio es tal que necesita tener una clave principal alfanumérica, entonces tiene que ir por varchar o nvarchar.

Estas son las dos opciones en las que podría pensar.

Un gran factor es la cantidad de datos que va a almacenar. Trabajo para una empresa de análisis web, y tenemos CARGAS de datos. Por lo tanto, una clave principal de GUID en nuestra tabla de visitas a página nos mataría, debido al tamaño.

Una regla general: para un alto rendimiento, debe poder almacenar todo su índice en la memoria. ¡Las guías podrían romper esto fácilmente!

Use llaves naturales cuando se pueda confiar. Algunas fuentes de claves naturales no se pueden confiar. Hace años, la Administración de Seguridad Social solía ocasionalmente arruinar y asignar el mismo SSN a dos personas diferentes. Probablemente ya hayan arreglado eso.

Probablemente pueda confiar en los VIN para vehículos y en los ISBN para libros (pero no para los panfletos, que pueden no tener un ISBN).

Si usa claves naturales, la clave natural determinará el tipo de datos.

Si no puede confiar en ninguna clave natural, cree una clave sintética. Prefiero los enteros para este propósito. Deje suficiente espacio para una expansión razonable.

¿Dónde lo generas? Incrementar el número no encaja bien con las claves generadas por el cliente.
- ¿Desea una clave dependiente de datos o independiente (a veces puede usar una ID de datos comerciales, no puede decir si esto siempre es útil o no)?
- ¿Qué tan bien puede este tipo ser indexado por su DB?

He utilizado uniqueidentifiers (GUID) o incrementos enteros hasta el momento.

Saludos Matías

Perdón por hacer eso, pero encontré que las respuestas que di a las preguntas relacionadas (puede verificar esto y esto ) podrían aplicarse a esta. Los rediseñé un poco ...

Encontrará muchas publicaciones relacionadas con este tema, y cada elección que haga tendrá sus pros y sus contras. Los argumentos para estos generalmente se refieren a la teoría de bases de datos relacionales y al rendimiento de la base de datos.

Sobre este tema, mi punto es muy simple: las claves primarias sustitutas SIEMPRE funcionan , mientras que las teclas naturales NO SIEMPRE pueden funcionar uno de estos días , y esto por varias razones: campo demasiado corto, cambios de reglas, etc.

Hasta este punto, has adivinado que básicamente soy un miembro del equipo uniqueIdentifier / subrogado primary key, e incluso si aprecio y entiendo argumentos como los presentados aquí, todavía estoy buscando el caso en el que "natural" la clave es mejor que la sustituta ...

Además de esto, uno de los argumentos más importantes pero siempre olvidados a favor de esta regla básica está relacionado con la normalización y la productividad del código :

cada vez que creo una tabla, ¿perderé tiempo?

identificando su clave primaria y sus características físicas (tipo, tamaño)
recordando estas características cada vez que quiero referirme a él en mi código?
explicando mi elección PK a otros desarrolladores en el equipo?

Mi respuesta es no a todas estas preguntas:

No tengo tiempo para perder el intento de identificar "la mejor clave primaria natural" cuando la opción sustituta me brinda una solución a prueba de balas.
No quiero recordar que la clave principal de mi Table_whatever es una cadena de 10 caracteres de longitud cuando escribo el código.
No quiero perder el tiempo negociando la longitud de la clave natural: "bueno, si necesitas 10, ¿por qué no tomas 12 para estar seguro ?". Este argumento de "en el lado seguro" realmente me molesta: si quieres estar seguro, significa que realmente no estás lejos del lado inseguro. Elige un sustituto: ¡es a prueba de balas!

Así que he estado trabajando durante los últimos cinco años con una regla muy básica: cada tabla (llamémosla ''myTable'') tiene su primer campo llamado ''id_MyTable'' que es de tipo uniqueIdentifier. Incluso si esta tabla admite una relación "muchos a muchos", donde una combinación de campos ofrece una clave principal muy aceptable, prefiero crear este campo ''id_myManyToManyTable'' como uniqueIdentifier, solo para cumplir con la regla y porque finalmente , No hace daño.

La principal ventaja es que ya no tiene que preocuparse por el uso de la clave principal y / o la clave externa en su código. Una vez que tenga el nombre de la tabla, conocerá el nombre y el tipo de PK. Una vez que sepa qué enlaces se implementan en su modelo de datos, sabrá el nombre de las claves externas disponibles en la tabla.

Y si aún desea tener su "Clave natural" en algún lugar de su tabla, le aconsejo que la cree siguiendo un modelo estándar tal como

Tbl_whatever id_whatever, unique identifier, primary key code_whatever, whateverTypeYouWant(whateverLengthYouEstimateTheRightOne), indexed .....

Donde id_ es el prefijo para la clave principal, y code_ se usa para el campo indexado "natural". Algunos argumentarían que el campo code_ debe establecerse como único. Esto es cierto y se puede administrar fácilmente a través de DDL o código externo. Tenga en cuenta que muchas claves "naturales" se calculan (números de factura), por lo que ya se generan a través del código

No estoy seguro de que mi regla sea la mejor. ¡Pero es muy eficiente! ¡Si todos lo aplicaran, por ejemplo, evitaríamos perder tiempo respondiendo a este tipo de preguntas!

Normalmente voy con una clave primaria de columna GUID para todas las tablas (rowguid en mssql). Lo que podrían ser claves naturales, hago restricciones únicas. Un ejemplo típico sería un número de identificación de producto que el usuario debe inventariar y asegurarse de que sea único. Si necesito una secuencia, como en una factura, creo una tabla para mantener un último número y un procedimiento almacenado para garantizar el acceso serializado. O una secuencia en Oracle :-) Odio la muestra del "número de la seguridad social" para claves naturales ya que ese número nunca estará siempre disponible en un proceso de registro. Resultando en una necesidad de un esquema para generar números ficticios.