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

La respuesta depende un poco si está limitado a software gratuito como PostGreSQL (no totalmente compatible con SQL), o si está pensando en SQL (es decir, compatible con SQL) y grandes bases de datos.

En compatibilidad con SQL, Arquitectura abierta bases de datos, donde hay muchas aplicaciones que usan una base de datos y muchos usuarios que usan diferentes herramientas de informes (no solo las aplicaciones) para acceder a los datos, los estándares, la normalización y los requisitos de arquitectura abierta son importantes.

A pesar de las personas que intentan cambiar la definición de "normalización", etc. para adaptarla a su propósito siempre cambiante, la normalización (la ciencia) no ha cambiado.

si tiene valores de datos como {Open; Closed; etc } repetido en tablas de datos, eso es duplicación de datos , un simple error de normalización:si esos valores cambian, es posible que deba actualizar millones de filas, lo cual es un diseño muy limitado.
- Dichos valores deben normalizarse en una tabla de referencia o de búsqueda, con un CHAR(2) corto. PK:
```
O  Open
C  Closed
U  [NotKnown]
```
- Los valores de datos {Open;Closed;etc } ya no se duplican en millones de filas. También ahorra espacio.
- el segundo punto es la facilidad de cambio, si Closed se cambiaron a Expired , nuevamente, se debe cambiar una fila, y eso se refleja en toda la base de datos; mientras que en los archivos no normalizados, se deben cambiar millones de filas.
- Agregar nuevos valores de datos , p.ej. (H,HalfOpen ) es simplemente una cuestión de insertar una fila.
en Arquitectura abierta términos, la tabla de búsqueda es una tabla ordinaria. Existe en el catálogo [compatible con SQL]; siempre que la FOREIGN KEY se ha definido la relación, la herramienta de informe también puede encontrar eso.
ENUM es un No-SQL, no lo use. En SQL, la "enumeración" es una tabla de búsqueda.
El siguiente punto se relaciona con el significado de la clave.
- Si la clave no tiene sentido para el usuario, está bien, use un {INT;BIGINT;GUID;etc } o lo que sea adecuado; no los numere de forma incremental; permitir "brechas".
- Pero si la clave es significativa para el usuario, no use un número sin sentido, use una clave relacional significativa.
Ahora algunas personas se irán por la tangente con respecto a la permanencia de los PK. Ese es un punto aparte. Sí, por supuesto, siempre use un valor estable para un PK (no "inmutable", porque no existe tal cosa, y una clave generada por el sistema no proporciona unicidad de fila).
- {M,F } es poco probable que cambie
- si ha utilizado {0,1,2,4,6 }, bueno, no lo cambies, ¿por qué querrías hacerlo? Se suponía que esos valores no tenían sentido, recuerde, solo se necesita cambiar una clave significativa.
- si usa claves significativas, use códigos alfabéticos cortos, que los desarrolladores puedan entender fácilmente (y deducir la descripción larga). Apreciará esto solo cuando codifique SELECT y date cuenta de que no tienes que JOIN cada tabla de búsqueda. Los usuarios avanzados también lo aprecian.
Dado que los PK son estables, especialmente en las tablas de búsqueda, puede codificar con seguridad:

WHERE status_code = 'O' -- Open

No tienes que hacerlo JOIN la tabla de búsqueda y obtener valor de datos Open , como desarrollador, se supone que debe saber qué significan los PK de búsqueda.

Por último, si la base de datos fuera grande y admitiera funciones BI, DSS u OLAP además de OLTP (como pueden hacerlo las bases de datos normalizadas), la tabla de búsqueda es en realidad una dimensión o un vector, en Dimension-Fact. análisis Si no estuviera allí, tendría que agregarse para satisfacer los requisitos de ese software, antes de que se puedan montar dichos análisis.

Si hace eso en su base de datos desde el principio, no tendrá que actualizarla (y el código) más adelante.

Tu ejemplo

SQL es un lenguaje de bajo nivel, por lo que es engorroso, especialmente cuando se trata de JOINs . Eso es lo que tenemos, así que solo tenemos que aceptar el estorbo y lidiar con él. Su código de ejemplo está bien. Pero los formularios más simples pueden hacer lo mismo.

Una herramienta de informe generaría:

SELECT p.*,
       s.name
    FROM posts  p, 
         status s
    WHERE p.status_id = s.status_id 
    AND   p.status_id = 'O'

Otro ejemplo

Para los sistemas bancarios, donde usamos códigos cortos que son significativos (ya que son significativos, no los cambiamos con las estaciones, solo los agregamos), dada una tabla de búsqueda como (elegido cuidadosamente, similar a los códigos de país ISO) :

Eq   Equity
EqCS Equity/Common Share
OTC  OverTheCounter
OF   OTC/Future

Código como este es común:

WHERE InstrumentTypeCode LIKE "Eq%"

Y los usuarios de la GUI elegirían el valor de un menú desplegable que muestra
{Equity/Common Share;Over The Counter },
no {Eq;OTC;OF }, no {M;F;U }.
Sin una tabla de búsqueda, no puede hacer eso, ni en las aplicaciones ni en la herramienta de informes.