¿Estas tablas específicas necesitan claves sustitutas?

Question

Fondo

tengo estas mesas

+-------------------------+  +------------------------+
|Airport                  |  |Country                 |
|-------------------------|  |------------------------|
|airport_code string (PK) |  |country_code string (PK)|
|address string           |  |name string             |
|name  string             |  +------------------------+
+-------------------------+

+-------------------------+
|Currency                 |
|-------------------------|
|currency_code string (PK)|
|name string              |
+-------------------------+

código_aeropuerto es el IATA (Asociación Internacional de Transporte Aéreo) código de aeropuerto, puedes verlos en las etiquetas de tu equipaje cuando viajas en avión.

código de país es el Código de país estándar ISO 3166-1 A3, puedes verlos en los juegos olímpicos.

código de moneda es el Código de moneda estándar de 3 caracteres IS0 417, puedes verlos en los tablones de anuncios de cambio de moneda internacional.

Preguntas

¿Son estas PK naturales lo suficientemente buenas?

¿El uso de estándares respetados a nivel mundial, que son aceptados por industrias enteras, es suficiente para las PK?

¿Estas mesas necesitan sustitutos pase lo que pase?

Answer 1

No, no lo hacen.Esas llaves son definitivamente lo suficientemente buenas!

Son únicos, no raramente que van a cambiar, y significativo , que es un paso hacia arriba sobre una clave sustituta.Eso es casi la definición de una buena pk.

Las restricciones sobre PKS que son inmutables y numéricas no son parte de la modelo relacional (CODD) oCualquier estándar de SQL (ANSI u otro).

Answer 2

Creo necesidad es una palabra muy fuerte, y en sentido estricto, las tablas probablemente no necesidad claves sustitutas.

Sin embargo, si fuera mi base de datos, probablemente agregaría claves sustitutas de todos modos.Es posible que no quiera necesariamente que el diseño de mi base de datos dependa de un grupo de terceros (IATA, ISO), independientemente de cuán estables sean sus estándares.O bien, es posible que no quiera depender en absoluto de un estándar en particular (¿existen otros estándares de códigos de moneda?No sé).Probablemente modelaría mis tablas con claves sustitutas así:

+-------------------------+  +------------------------+
|Airport                  |  |Country                 |
|-------------------------|  |------------------------|
|airport_id       int (PK)|  |country_id     int (PK) |
|iata_airport_code string |  |iso_country_code string |
|icao_airport_code string |  +------------------------+
|faa_identifier    string |  
|address           string |  
|name              string |  
+-------------------------+

+-------------------------+
|Currency                 |
|-------------------------|
|currency_id int (PK)     |
|iso_currency_code string |
|name string              |
+-------------------------+

En otras palabras, a menos que esos códigos estándar de la industria sean inherentemente importante para mi aplicación, no los usaría como PK de mis tablas.Son sólo etiquetas.La mayoría de mis otras tablas probablemente tendrán claves sustitutas de todos modos, y esta configuración agregaría coherencia a mi modelo de datos.El costo de "agregar" las claves sustitutas es mínimo.

Actualización basada en algunos de los comentarios:

Sin conocer el contexto de las tablas de ejemplo, es imposible saber qué tan importantes son cosas como los códigos de aeropuerto IATA para la aplicación que utiliza la base de datos.Obviamente, si los códigos IATA son de importancia central y se utilizan de manera generalizada en toda la aplicación, podría ser la decisión correcta, después de un análisis adecuado, utilizar los códigos como PK de la tabla.

Sin embargo, si la tabla es sólo una tabla de búsqueda que se utiliza en algunos rincones de la aplicación, la importancia relativa de los códigos IATA puede no justificar un lugar tan destacado en la infraestructura de la base de datos.Claro, es posible que tengas que unirte a algunas consultas aquí y allá, pero ese esfuerzo puede ser trivial en comparación con el esfuerzo que tomaría hacer la investigación para asegurar que entiendes completamente las implicaciones de hacer que los códigos IATA sean los más importantes. campo de clave principal.En algunos casos, no sólo no me importa, sino que no quiero tener que preocuparme sobre los códigos IATA.El comentario de @James Snell a continuación es un ejemplo perfecto de algo de lo que quizás no quisiera preocuparme por afectar la PK de mis tablas.

Además, la coherencia en el diseño es importante.Si tiene una base de datos con docenas de tablas que tienen claves sustitutas diseñadas de manera consistente, y luego algunas tablas de búsqueda que utilizan códigos de terceros como PK, eso introduce una inconsistencia.Eso no es del todo malo, pero requiere atención adicional en la documentación y cosas que pueden no estar justificadas.Ellos son tablas de búsqueda Por el amor de Dios, simplemente usar una clave sustituta para mantener la coherencia está perfectamente bien.

Actualización basada en investigaciones adicionales:

Ok, me picó la curiosidad y decidí investigar un poco sobre los códigos de aeropuerto IATA por diversión, comenzando con los enlaces proporcionados en la pregunta.

Resulta que los códigos IATA no son tan universales y autorizados como parece ser la pregunta.De acuerdo a esta página:

La mayoría de los países utilizan cuatro caracteres. códigos OACI, no códigos IATA, en sus publicaciones aeronáuticas oficiales.

Además, los códigos IATA y los códigos ICAO son distintos de Códigos identificadores de la FAA, que son otra forma más de identificar aeródromos.

Mi objetivo al mencionar esto no es iniciar un debate sobre qué códigos son mejores, más universales, más autorizados o más completos, sino mostrar exactamente por qué diseñar la estructura de su base de datos en torno a un identificador arbitrario de un tercero no es algo que elegiría hacer. , a menos que hubiera una razón comercial específica para hacerlo.

En este caso, Siento mi base de datos estaría mejor estructurada, sería más estable y más flexible si renunciara a los códigos IATA (o cualquier código de terceros potencialmente modificable) como candidato a clave principal y utilizara una clave sustituta.Al hacerlo, puedo evitar posibles problemas que puedan surgir debido a la selección de la clave principal.

Answer 3

Mientras que tener claves sustitutas en los campos está bien y no hay nada de malo en que algo que considere puede ser el tamaño de la página del índice.

Dado que esta es una base de datos relacional que estará haciendo muchas uniones y tener una clave sustituta de un tipo numérico podría facilitar que la base de datos maneje, es decir, el tamaño de la página de índice será más pequeño y, por lo tanto, más rápido para buscar a través del canal . Si este es un proyecto pequeño, no importará y lo pasará sin ningún problema, sin embargo, más grande la aplicación obtiene, más querrá reducir los cuellos de botella.

Tener un bigint, int, smallint, tinyint o cualquier tipo de datos en forma de entero, puede ahorrarle algunos problemas en la carretera.

solo mis 2 centavos

Actualizar:

Pequeño proyecto: utilizado por unos pocos, tal vez incluso unas pocas docenas de personas. Pequeño proyecto de demostración, proyecto para uso personal, algo para agregar a una cartera al presentar sus habilidades sin experiencia, y similares.

Proyecto grande: usado por miles, decenas de miles, millones de usuarios diarios. Algo que construiría para una compañía nacional / internacional con una gran base de usuarios.

Por lo general, lo que sucede es un selecto pocos de los registros se seleccionan a menudo, y el servidor almacena los resultados de acceso rápido, pero de vez en cuando necesitas acceder a un registro menos usado, momento en el que el servidor tendría que secar el servidor. en la página de índice. (En el ejemplo anterior con los nombres de los aeropuertos, las personas a menudo vuelan con líneas aéreas nacionales, dicen Chichago -> Los Ángeles, pero ¿con qué frecuencia vuela la gente de Boston -> Zimbabwe)

Si se usa VARCHAR, lo que significa que el espaciado no es uniforme, a menos que los datos siempre sean la misma longitud (en la que el punto de que un valor de caracteres sea más efectivo). Esto hace que busque el índice más lento, y con el servidor que ya está ocupando manejo de miles y miles de consultas por segundo ahora tiene que perder el tiempo a través de un índice no uniforme y hacer lo mismo nuevamente en las uniones (que es más lento que Selecciona regular en una tabla no optimizada, tome DW como ejemplo, donde existen tan pocas uniones como sea posible para acelerar la recuperación de datos). Además, si usa UTF, también puede meterse con el motor de la base de datos (he visto algunos casos).

Personalmente, de mi propia experiencia, un índice organizado adecuadamente puede aumentar la velocidad de un ~ 70%, y hacer una unión en una columna entera puede acelerar la unión hasta alrededor de aproximadamente ~ 25% (dependiendo de los datos). A medida que las tablas principales comienzan a crecer y estas tablas se utilizan en ellas, preferiría que un tipo de datos entero ocupe la columna que tiene algunos bytes vs que tiene un campo VarChar / char que ocupará más espacio. Se reduce a ahorrar en el espacio en disco, aumentar el rendimiento y la estructura general de una base de datos relacional.

también, como mencionó James Snell:

Las teclas primarias también deben ser inmutables, algo que los códigos del aeropuerto de IATA no están definitivamente. Se pueden cambiar al capricho de la IATA.

Tomando esto en consideración, preferiría que tenga que actualizar 1 registro que está unido a un número, vs teniendo que actualizar ese registro más todos los registros en la tabla en la que se une a.

Answer 4

Si toma el enfoque de "Yo utilizo las teclas de sustitución de sus hijos", debe pasar por alto este tipo de preocupación. Eso puede no ser algo bueno porque es importante darles un pensamiento a sus datos, pero ciertamente ahorra mucho tiempo, gergia y esfuerzo. Si alguien adoptara una concepción a esta regla, los ejemplos enumerados ciertamente califican porque se necesita un "acto del Congreso" cercano para hacer el cambio.

Las consultas ad hoc de una base de datos con estas llaves naturales ciertamente son útiles. La creación de puntos de vista que hagan lo mismo por las que las tablas de búsqueda también pueden funcionar. Las bases de datos modernas hacen un trabajo mucho mejor con este tipo de cosas hasta el punto en que probablemente no importa.

Hay algunos casos específicos para los EE. UU., Donde los estándares fueron modificados drásticamente: el código postal se expandió de 5 a 9 dígitos, las abreviaturas estatales a una de las 2 letras consistentes y deshacerse del período (recuerde cuando Illinois estaba enfermo.), Y la mayor parte del mundo tiene que lidiar con Y2K. Si tiene una aplicación en tiempo real con los datos difundidos en todo el mundo que contienen miles de millones de registros, las actualizaciones en cascada no son la mejor idea, ¡pero no deberíamos trabajar en lugares que enfrentan tales desafíos? Con ese conjunto de datos, podría probarlo por sí mismo y venir con una respuesta más difinitiva.