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?¿Qué debería considerar al seleccionar un tipo de datos para mi clave principal?
Lamento hacer eso, pero encontré que las respuestas que di a las preguntas relacionadas (puede marcar this y this) podrían aplicarse a esta. Los rediseñé un poco ...
Encontrarás muchas publicaciones relacionadas con este tema, y cada opción que elijas tiene 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: claves principales sustitutos siempre trabajo, mientras teclas natural no podría funcionar siempre uno de estos días, y esto por varias razones: campo demasiado cortos, las reglas cambian, etc.
Hasta ahora, ha adivinado que básicamente soy un miembro del equipo uniqueIdentifier/subrogado primary key, e incluso si aprecio y entiendo argumentos como los presentados aquí, soy sigue buscando el caso donde la clave "natural" es mejor que el sustituto ...
Además de esto, uno de los argumentos más importantes, pero siempre olvidados en favor de esta regla básica tiene que ver con la normalización código y la productividad:
cada vez que crear una tabla, tengo de perder el tiempo
Mi respuesta es no a todas estas preguntas:
Así que he estado trabajando durante los últimos cinco años con una regla muy básica: cada mesa (vamos a llamarlo '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 un identificador único, solo para seguir la regla y, finalmente, no lastima.
La principal ventaja es que ya no tiene que preocuparse por el uso de la clave principal y/o 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 todavía quiere tener su lugar "clave natural" en su mesa, yo te aconsejo que lo construye siguiendo un modelo estándar, como
Tbl_whatever
id_whatever, unique identifier, primary key
code_whatever, whateverTypeYouWant(whateverLengthYouEstimateTheRightOne), indexed
.....
Dónde ID_ es el prefijo de clave primaria, 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!
Si usa una clave numérica, asegúrese de que el tipo de datos es giong para que sea lo suficientemente grande como para contener el número de filas en las que puede 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 utiliza claves compuestas, ¿está seguro de que las columnas combinadas siempre serán únicas?
Siempre uso un número entero, pero aquí hay una perspectiva interesante.
Soy parcial a la utilización de una tecla de número entero generado. Si espera que la base de datos crezca demasiado, puede ir con bigint.
A algunas personas les gusta usar las guías. 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.
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.
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 primaria alfanumérica, entonces tiene que ir por varchar o nvarchar.
Estas son las dos opciones que se me ocurren.
En la mayoría de los casos utilizo una clave primaria identity int, a menos que el escenario requiera mucha replicación, en cuyo caso puedo optar por un GUID.
I (casi) nunca usé llaves significativas.
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.
No me gusta esto porque las reglas de negocio cambian. Quizás en el futuro necesite registrar un registro cada hora porque las cosas se han vuelto más ocupadas, o un registro por ubicación de tienda en lugar de un registro. – CindyH
Buen punto Cindy. Además, cualquier cosa que no sea un GUID es una mierda para la replicación. –
Creo que debería ser al revés: una clave sustituta debe ser la primera opción; una clave natural puede usarse solo cuando hay alguna razón realmente fuerte para hacerlo. De acuerdo con mi propia experiencia, las claves naturales podrían justificarse solo en proyectos extravagantes, únicos ... – Yarik
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.
¿Quién podría pensar en utilizar un número de coma flotante como índice? –
De hecho, conozco al menos tres desarrolladores que han intentado esto en alguna ocasión. (Yo no, por supuesto, porque leí _Código completo_ al principio.) Solo porque algo parece evidentemente malo no significa que las personas no lo hagan. –
¿Por qué en la Tierra alguien rechazaría la respuesta de Jeffrey? – Yarik
uniqueidentifiers que he utilizado (GUID) o enteros que se incrementan hasta el momento.
Saludos Matthias
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 de oro: para un alto rendimiento, debería poder almacenar todo su índice en la memoria. ¡Las guías podrían romper esto fácilmente!
No me gusta mucho 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 primaria compuesta de 2 o más campos. Nunca haria eso. Así que aquí está mi pequeño consejo:
EDITAR:
Bien, creo que necesito explicar mis elecciones un poco.
Tener una columna dedicada namend el mismo en todas mesa para que la clave principal, sólo hace que su SQL Declaraciones-una gran cantidad de más fácil de construir y más fácil para otra persona (que podrían no estar familiarizados con el diseño de base de datos) Más fácil de entender. 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 versus 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.
Pero si sigue esta técnica, debe asegurarse de que haya una restricción ÚNICA en las 2 o más columnas que de lo contrario podrían ser la clave principal. –
Nos ha dicho lo que le gusta pero no nos ha dicho ** por qué ** –
Si no necesita rendimiento (es decir, una tabla pequeña), ¿por qué usar algo así como un GUID? Los GUID solo deberían usarse cuando planee tener una gran cantidad de datos. – Kibbee
números que tienen significado en el mundo real son por lo general una mala idea, porque de vez en cuando el mundo real cambia las reglas acerca de cómo se utilizan esos números, en particular para permitir duplicados, y entonces usted tiene un verdadero desastre en tus manos.
Use las teclas naturales cuando sean confiables. 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 folletos, que pueden no tener un ISBN).
Si utiliza teclas 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.
"Usar claves naturales cuando se puede confiar en ellas": no se puede confiar siempre en las claves naturales. ¡Entonces no uses llaves naturales! –
A menos que se ocupe de un proyecto único, a corto plazo, nunca confíe en llaves naturales. Eventualmente las llaves naturales fallan. A veces mucho antes de lo que cualquiera esperaría. Muy por el contrario, las claves sustitutivas/sintéticas son a prueba de balas. Por definición. – Yarik
A menos que tenga una clave natural ultra conveniente disponible, utilice siempre una clave sintética (por ej., Sustituta) 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 asignar el mismo nombre a cada tecla principal, p. Ej. "carné de identidad". 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.
Estoy de acuerdo con el primer punto. Y no estoy de acuerdo con el segundo. Pero el segundo es probablemente menos crítico que el primero. De ahí un voto positivo. – Yarik
Estoy de acuerdo en ambos puntos, pero el segundo es puramente sabor - pestañas vs. espacios, /*...*/ vs // ... –
Normalmente voy con una clave principal 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.
Esto es lo que he hecho también. A la baja: (a) a veces es necesario realizar uniones adicionales, p. tienes invoice_line_item.invoice_id pero realmente quieres el invoice_number. (b) puede ser difícil comparar bases de datos (c) sobrecarga en tablas grandes con pocas columnas (d) puede afectar la capacidad de partición –
Hay algunos "inconvenientes" pero la principal ventaja es que "siempre funciona" ... –
Gran explicación: hago lo mismo, a veces agrego una restricción/clave única en lo que hubiera sido la clave natural. –