what traductor primary foreign español ejemplo database database-design primary-key

database - traductor - Escogiendo la mejor clave primaria+sistema de numeración



what is a foreign key (13)

Como se mencionó anteriormente, mantenga sus claves primarias internas como solo claves, cualquiera que sea el tipo de datos más óptimo en su plataforma.

Sin embargo, debe dejar que se resuelva el argumento del sistema de numeración, ya que esto es realmente un requisito comercial, y quizás lo llamemos un sistema de identificación para el activo.

Si solo va a haber un identificador, entonces agréguelo como una columna a la tabla principal. Si es probable que haya muchos sistemas de identificación (y los activos usualmente tienen muchos), necesitará dos tablas más

Identifier-type table Identifier-cross-ref table type-id ------------> type-id (unique type-name identifier-string key) internal-id

De esta forma, diferentes personas que necesitan acceder al activo pueden identificarse a su manera. Por ejemplo, el equipo del servidor identificará un servidor diferente del equipo de red y diferente de la administración del proyecto, cuentas, etc.

Además, puedes ir a todas las reuniones donde todos discuten entre sí.

Estamos tratando de idear un sistema de numeración para el sistema de activos que estamos creando, ha habido algunas discusiones acaloradas sobre este tema en la oficina, así que decidí preguntar a los expertos de SO.

Teniendo en cuenta el diseño de la base de datos a continuación, ¿cuál sería la mejor opción?

Ejemplo 1: Usar claves de sustitución automática.

================= ================== Road_Number(PK) Segment_Number(PK) ================= ================== 1 1

Ejemplo 2: uso de PK generado por programa

================= ================== Road_Number(PK) Segment_Number(PK) ================= ================== "RD00000001WCK" "00000001.1"

(el 00000001.1 significa que es el primer segmento de la carretera. Esto aumenta cada vez que agrega un nuevo segmento, por ejemplo, 00000001.2 )

Ejemplo 3: usar un poco de ambos (agregar una nueva columna)

======================= ========================== ID(PK) Road_Number(UK) ID(PK) Segment_Number(UK) ======================= ========================== 1 "RD00000001WCK" 1 "00000001.1"

Solo un poco de información de antecedentes, utilizaremos el Road Number y el Segment Number en informes y otros documentos, por lo que deben ser únicos .

Siempre me ha gustado mantener las cosas simples, así que prefiero el ejemplo 1, pero he estado leyendo que no debe exponer sus claves principales en informes / documentos. Así que ahora estoy pensando más en la línea del ejemplo 3.

También me inclino por el ejemplo 3 porque si decidimos cambiar la forma en que se genera nuestra numeración de activos, no tendrá que hacer actualizaciones en cascada en una clave principal.

¿Qué crees que deberíamos hacer?

Gracias.

EDITAR: Gracias a todos por las excelentes respuestas, me ha ayudado mucho.

Creo que lo importante de recordar aquí es que cada tabla de su base de datos / diseño puede tener varias claves. Estas son las Claves Candidatas . Ver la entrada de Wikipedia para Candidate Keys

Por definición, todas las claves candidatas se crean iguales. Son identificadores únicos para la tabla en cuestión.

Su trabajo consiste entonces en seleccionar al mejor candidato del conjunto de claves candidatas para que actúe como clave principal . La clave principal será utilizada por otras tablas para establecer las restricciones relacionales, pero puede continuar utilizando las claves candidatas para consultar la tabla.

Como las claves primarias son referenciadas por otras estructuras y, por lo tanto, se usan en operaciones de unión, los criterios para la selección de clave primaria se reducen a lo siguiente para mí (en orden de importancia):

  • Inmutable / Estable : los valores de las claves primarias no deberían cambiar. Si lo hacen, corre el riesgo de introducir anomolías de actualización
  • No nulo : la mayoría de las plataformas DBMS requieren que los atributos de la clave principal no sean nulos
  • Tipos de datos simples y simples y valores para el almacenamiento físico y el rendimiento. Los valores enteros funcionan bien aquí, y este es el tipo de datos de elección para la mayoría de las claves sustitutas / auto gen

Una vez que haya identificado las Candidate Keys, los criterios anteriores se pueden utilizar para seleccionar la clave principal. Si no hay una Clave candidata "natural" que cumpla con los criterios, se puede crear y utilizar una Clave sustituta que cumpla con los criterios, tal como se menciona en otras respuestas.

En primer lugar, la opción 2 es la peor opción absoluta. Como índice, es una string , y eso lo hace lento. Y se genera según reglas comerciales, que pueden cambiar y causar un gran dolor de cabeza.

Personalmente, siempre utilizo una columna de clave primaria separada; y siempre uso un GUID. Algunos desarrolladores prefieren una INT simple sobre un GUID por razones de espacio en el disco duro. Sin embargo, si surge la situación en la que necesita fusionar dos bases de datos, los GUID casi nunca colisionarán (mientras que las INT están garantizadas para colisionar).

Las llaves principales NUNCA deben ser vistas por el usuario. Hacerlo legible para el usuario no debería ser una preocupación. Las claves primarias DEBERÍAN utilizarse para vincular con las claves externas. Este es su propósito. El valor debe ser legible por máquina y, una vez creado, nunca cambiará.

Espero que estén de acuerdo conmigo en que cada elemento de diseño debe tener un único propósito.

La pregunta es ¿cuál crees que es el propósito de PK? Si se trata de identificar registros únicos en una tabla, las claves sustitutas ganan sin muchos problemas. Esto es simple y directo.

En lo que respecta a las columnas nuevas en la opción 3, debe verificar si se pueden calcular (lo mejor sería hacer el cálculo en la capa del modelo para que puedan cambiarse fácilmente si el cálculo se hace en RDBMS) sin demasiada penalización de rendimiento de otros elementos Por ejemplo, puede almacenar el número de segmento y el número de ruta en las tablas correspondientes y luego usarlos para generar "00000001.1". Esto permitirá cambiar la numeración de activos sobre la marcha.

Esta es realmente una discusión sobre las claves primarias sustitutas (también denominadas técnicas o sintéticas) frente a naturales, un tema que ha sido extensamente cubierto. Cubrí esto en Errores de desarrollo de base de datos realizados por AppDevelopers .

Las claves naturales son claves basadas en datos externamente significativos que (ostensiblemente) son únicos. Ejemplos comunes son códigos de productos, códigos de estado de dos letras (EE. UU.), Números de la seguridad social, etc. Las claves primarias subrogadas o técnicas son aquellas que no tienen ningún significado fuera del sistema. Se inventan puramente para identificar a la entidad y suelen ser campos que se autoincrementan (SQL Server, MySQL, otros) o secuencias (sobre todo Oracle).

En mi opinión, siempre debes usar claves sustitutivas. Este problema ha surgido en estas preguntas:

Los campos de números automáticos son el camino a seguir. Si sus claves tienen un significado fuera de su base de datos (como los números de activos), es muy posible que cambien y cambiar las claves es problemático. Simplemente use índices para esas cosas en las tablas relevantes.

Me gustaría ir con la clave sustituta, pero es posible que desee tener una columna calculada que "formatee" la clave sustituta en un valor más "legible" si eso mejora su informe. La columna calculada podría producir el ejemplo 2 a partir de la clave sustituta, por ejemplo, para fines de visualización.

Creo que la ruta clave sustituta es el camino a seguir y las únicas excepciones que hago son las tablas de unión, donde la clave primaria podría estar compuesta por las referencias de clave externa. Incluso en estos casos, descubro que tener una clave primaria sustituta es más útil que no tenerla.

No pongas significado en tus campos PK a menos que ...

  • Es 100% completamente imposible que el valor nunca cambie y que

  • No hay dos personas alguna vez razonablemente
    discutir sobre qué valor debería ser
    utilizado para una fila en particular.

Vaya con la opción uno y formatee el valor en la aplicación para que se vea como la opción dos o tres cuando se muestre.

Otra cosa a tener en cuenta es que si está importando una gran cantidad de datos en este sistema, puede descubrir que cosas como Road_Number no son tan exclusivas como pensaba, y puede haber obstáculos operativos para solucionar el problema (volver a pintar las señales de tráfico) , etc.)

Si bien las llaves naturales pueden tener un gran significado para los usuarios comerciales, si no tiene el acuerdo de que esas llaves son sagradas y no deben modificarse, lo más probable es que se quite el pelo mientras mantiene una base de datos donde los "códigos de productos tienen para ser modificado para acomodar la nueva línea de productos que la compañía adquirió ". Necesita proteger el RI de sus datos, y los enteros como claves primarias con incremento automático, es la mejor manera de hacerlo. El rendimiento también es mejor al indexar y atravesar enteros que las columnas char.

Aunque no son apropiadas como claves principales, las claves naturales son muy apropiadas para el consumo del usuario y usted puede aplicarlas a través de un índice. Traen un contexto a los datos que hará que sea más fácil de entender para todas las partes. Además, en el caso de que necesite volver a cargar datos, las claves naturales pueden ayudarlo a verificar que sus búsquedas aún sean válidas.

Sigue la política No usar.

Algunos problemas que puede encontrar:

Necesita generar claves de más de un host.

Alguien querrá reservar números contiguos para usar juntos.

¿Cuán significativa quiere la gente que sea? Las guerras se pelean por esto, y ya estás en la primera escaramuza de uno. "Ya es significativo, y si solo agregamos dos dígitos más, podemos ...", es decir, estás estableciendo un estilo de diseño que (de hecho) debería ser extensible.

Si concatenas a los dos, estás haciendo tipos de letra que pueden estropear tu consulta Optimizer.

Tendrá que reclasificar las carreteras y redefinir sus límites (es decir, mover las carreteras), lo que implica cambiar la clave principal y quizás perder enlaces.

Hay soluciones para todo esto, pero este es el tipo de problema donde las soluciones proliferan y se salen de control. Y no hace falta más de un par para ir más allá de "Simple".

Sospecho que deberías usar la opción n. ° 3, como muchos ya han dicho. Las PK sustitutas (ya sean enteros o GUID) son buenas prácticas, incluso si existen claves comerciales adecuadas. Los sustitutos reducirán los dolores de cabeza de mantenimiento (como usted mismo ya ha notado).

Dicho esto, algo que tal vez quiera considerar es si su base de datos es o no:

  1. se centró en el mantenimiento de datos y el procesamiento transaccional (es decir, operaciones de creación / actualización / eliminación)
  2. orientado a análisis e informes (es decir, consultas)

En otras palabras, ¿los usuarios están interesados ​​en mantener datos activos o consultar datos en gran parte estáticos para encontrar respuestas?

Si está muy concentrado en construir un análisis e informe DB (por ejemplo, un data warehouse / mart) que está expuesto a los usuarios comerciales técnicos (por ejemplo, diseñadores de informes) que tienen una buena comprensión del vocabulario comercial, entonces puede considerar usar claves basadas en valores comerciales significativos. Ayudan a reducir la complejidad de las consultas al eliminar la necesidad de uniones complejas y ayudar al usuario a concentrarse en sus tareas, sin luchar contra la estructura de la base de datos.

De lo contrario, probablemente estés enfocado en un DB CRUD completo que tiene que cubrir todas las bases hasta cierto punto, esta es la gran mayoría de las situaciones. En ese caso, vaya con su opción n. ° 3. Siempre puede optimizar la posibilidad de consultas en el futuro, pero será difícil modernizarla para mantenerla.

También estoy muy interesado en el campo "No utilizar claves primarias como datos significativos". Cada vez que he contravenido esa política, ha terminado en lágrimas. Tarde o temprano, los datos significativos deben cambiar y si eso significa que debe cambiar una clave principal, puede ser doloroso. La clave principal probablemente se utilizará en restricciones de clave externa y puede pasar siglos tratando de resolver todo solo para hacer un cambio de datos simple.

Siempre utilizo GUID / UUID para mis claves principales en todas las tablas que he creado, pero eso solo son las preferencias personales o las que son también buenas.

Yo personalmente diría que sea simple y que permanezca con una clave primaria autoincrementada. Si necesita algo más "Legible" en términos de visualización en el programa, entonces posiblemente una de sus otras ideas, pero creo que eso simplemente agrega complejidad innecesaria al campo de clave principal.