¿Cuáles son las mejores prácticas con respecto a las tablas de búsqueda en bases de datos relacionales?

Las tablas de búsqueda (o tablas de códigos , como algunas personas las llaman) suelen ser una colección de los posibles valores que se pueden dar para una determinada columna.

Por ejemplo, supongamos que tenemos una tabla de búsqueda llamada party(destinada a almacenar información sobre partidos políticos) que tiene dos columnas:

• party_code_idn, que contiene valores numéricos generados por el sistema y (sin significado del dominio comercial ) funciona como un sustituto de la clave real.
• party_code, es la clave real o "natural" de la tabla porque mantiene valores que tienen connotaciones de dominio empresarial .

Y digamos que dicha tabla retiene los siguientes datos:

 +----------------+------------+
 | party_code_idn | party_code |
 +----------------+------------+
 |              1 | Republican |
 |              2 | Democratic |
 +----------------+------------+

La party_codecolumna, que mantiene los valores 'Republicano' y 'Democrático', siendo la clave real de la tabla, está configurada con una restricción ÚNICA, pero opcionalmente agregué el party_code_idny lo definí como el PK de la tabla (aunque, lógicamente hablando , party_codepuede funcionar como la CLAVE PRIMARIA [PK]).

Pregunta

¿Cuáles son las mejores prácticas para señalar valores de búsqueda de tablas de transacciones ? ¿Debo establecer referencias de CLAVE EXTRANJERA (FK) ya sea (a) directamente al valor natural y significativo o (b) a los valores sustitutos?

Opción (a) , por ejemplo,

 +---------------+------------+---------+
 | candidate_idn | party_code |  city   |
 +---------------+------------+---------+
 |             1 | Democratic | Alaska  |
 |             2 | Republican | Memphis |
 +---------------+------------+---------+

tiene las siguientes propiedades ¹ :

1. Legible para el usuario final (+)
2. Fácil de importar-exportar a través de sistemas (+)
3. Difícil de cambiar el valor ya que necesita modificación en todas las tablas de referencia (-)
4. Agregar nuevo valor no es costoso (=)

Creo que es casi como " pasar por valor ", para dibujar una analogía de la llamada a la función en la jerga de programación de aplicaciones.

Opción (b) , por ejemplo,

 +---------------+----------------+---------+
 | candidate_idn | party_code_idn |  city   |
 +---------------+----------------+---------+
 |             1 |              1 | Alaska  |
 |             2 |              2 | Memphis |
 +---------------+----------------+---------+

tiene las siguientes propiedades:

1. No legible para el usuario final (-)
2. Difícil de importar-exportar ya que necesitamos desreferenciarlo (-)
3. Valores fáciles de cambiar, ya que solo almacenamos referencias en tablas de transacciones (+)
4. Agregar nuevo valor no es costoso (=)

Es muy similar a " pasar por referencia ", si se compara con la llamada de función en el lenguaje de programación de aplicaciones.

Importar-Exportar también se puede hacer de una manera diferente, es decir, simplemente rellenando la tabla de búsqueda nuevamente y luego volviendo a sembrar la columna sustituta. Espero estar entendiendo bien, esto es algo que acabo de escuchar como una posibilidad.

_{1. Tenga en cuenta que +, -y =indicar el beneficio de esas propiedades.}

Pregunta

Muy importante: ¿Hay alguna diferencia entre una tabla de búsqueda (o código ) y una referencia de FK si solo vamos a usar este último enfoque? Creo que funcionan igual.

Recursos Relacionados

• ¿Qué tan importantes son las tablas de búsqueda?

• Mejores prácticas con código o tablas de búsqueda

• Tablas de búsqueda Mejores prácticas Tablas o enumeraciones de bases de datos

Por IDN, lo tomo quiere decir una IDENTITY, SEQUENCEo AUTO_INCREMENTcampo? Deberías echar un vistazo aquí y aquí .

Tenga en cuenta que la sección 5 (Uso incorrecto de los valores de datos como elementos de datos) de la primera referencia, debajo de la figura 10

Por supuesto, puede tener una tabla separada para los vendedores y luego hacer referencia a ella utilizando una clave foránea, preferiblemente con una clave sustituta simple como sales_person_id, que se muestra arriba.

Por lo tanto, este experto cree que debe "deferencia" claves sustitutas. Realmente es una técnica SQL bastante básica y no debería causar problemas en su SQL diario. Parece que hay un error en la figura 10: sales_person en SalesData debe ser una clave sustituta (es decir, un número), no texto. Estoy deduciendo esto de la cita anterior.

Lo que debe evitar a toda costa es la tentación (muy común para los programadores de bases de datos novatos) de cometer el error descrito en la sección (1) Tablas de búsqueda comunes. Esto se conoce comúnmente como el enfoque MUCK ( clave de código masivamente unificado ) (no por accidente :-) en particular por Joe Celko , también conocido sarcásticamente como OTLT - One True Lookup Table ) y conduce a todo tipo de dificultades. Los programadores novatos parecen sentir que un solo código / búsqueda / cualquier tabla es "más limpia" y será más eficiente cuando nada podría estar más lejos de la verdad.

De la segunda referencia anterior:

La normalización elimina los datos redundantes, lo que hace que la tarea de hacer cumplir la integridad de los datos sea mucho más simple, pero el proceso de creación de un MUCK es algo completamente diferente. Como demostraré, menos tablas no equivalen a simplicidad.

También es posible que desee echar un vistazo al paradigma relacionado EAV ( Entity Attribute Value ) que trato aquí .

Hay un tercer enfoque que tiene algunas de las ventajas de sus dos opciones: poner un código real en la tabla de códigos. Con esto quiero decir una secuencia de caracteres corta que captura la esencia del valor total y es única. Para su ejemplo dado puede ser

Idn: 1
Name: Democrats
Code: D      (or DEM)

El Código se lleva a las tablas transaccionales como una clave externa. Es breve, inteligible y algo independiente de los datos "reales". Los cambios incrementales al nombre no sugerirían un cambio de código. Sin embargo, si los republicanos se acampan en masa , puede ser necesario un cambio de código, con sus problemas concomitantes en los que no incurriría una identificación sustituta.

Este estilo se ha denominado codificación abreviada. Puedo recomendar la escritura de Celko sobre esto. Google books tiene varios ejemplos. Busque "codificación Celko".

Otros ejemplos: codificaciones de 2 o 3 letras para países, codificación de 3 letras (GBP, USD, EUR) para códigos de moneda. Corto, autoexplicativo y sin cambios (y hay un ISO para ellos).