¿Cuándo considerar tablas de referencia?

Question

Al pensar en una aplicación. Digamos los detalles del usuario de una aplicación.

Digamos que la aplicación permite al usuario editar fácilmente su perfil.

Para un campo como género, que en la mayoría de los casos estará marcado como MF u otro. Si esos valores se almacenan en una tabla de referencia, por ejemplo.

Y mi pregunta principal es, ¿cuándo comienza a hacer que su aplicación se involucre demasiado con un esquema como un esquema en estrella que termina no siendo tan útil para transacciones rápidas?

Me preocupo cuando empiezas a dividir todo en hechos y dimensiones, terminamos con una base de datos de informes con la que una aplicación puede no funcionar de manera tan eficiente.

Answer 1

Todo es cuestión de intención y equilibrio. Depende de usted tomar su decisión.

Si coloca Gendervalores en una tabla de referencia, tiene los siguientes beneficios:

• fácil personalización de valores;
• fácil localización de su código a otros idiomas;
• extensión relativamente fácil de valores posibles;
• Uniformización / generericidad de las consultas y presentación: se utiliza el mismo enfoque para todas las tablas de referencia.

Además, si Genderes solo descriptivo y sin impacto en el comportamiento de la aplicación, ya no tendrás que preocuparte por los posibles valores, y ni siquiera necesitarás una enumeración, obteniendo un sistema muy flexible. Por otro lado, si tiene un comportamiento específico para algunos valores, tendrá solo una flexibilidad parcial.

Si no pone Genderen una tabla de referencia, tiene los siguientes beneficios:

• mejor control de los valores permitidos y el comportamiento relacionado,
• un par de bytes de la tabla de referencia guardados (pero con el tamaño de una base de datos, esto no hará ninguna diferencia)
• mayor rendimiento, evitando una combinación (esto se aplica a las bases de datos NoSql donde la combinación puede requerir una búsqueda adicional; esto no es un argumento para un RDBMS, donde el optimizador de todos modos buscaría el carácter de referencia y almacenaría en caché los datos para realizar la combinación sin ningún tipo de gastos generales significativos)
• mayor flexibilidad para la presentación, cuando se puede generar el valor mostrado (especialmente si su idioma permite valores asociados como swift)

En mi propia experiencia, el primer enfoque resultó muy útil para simplificar el código y su reutilización. Pero puedo imaginar que el segundo enfoque podría superar estas ventajas en algunas circunstancias (especialmente en un contexto nosql).

Prefiero no responder a la pregunta más general sobre el esquema en estrella, porque depende mucho de los dbms subyacentes, pero también de los patrones de acceso y, además, de los patrones de escritura; además, la estrella sin tablas de referencia puede ser inevitable dependiendo de los requisitos.

Answer 2

Me inclino por las tablas de referencia en una base de datos relacional por una razón muy simple: la "C" en ACID .

La coherencia es beneficiosa, no solo para los programadores, sino también para los usuarios. He trabajado en bases de datos donde campos como este eran solo texto. La interfaz de usuario mostraba un menú desplegable o un grupo de botones de opción, haciéndolo aparecer como una enumeración, pero a nivel de datos era solo texto abierto. Con el paso del tiempo, la lista de valores cambió, pero los registros antiguos no se actualizaron. La gente creaba informes y consultas de bases de datos ad-hoc esperando encontrar un registro que se filtraba accidentalmente porque era un registro antiguo con un valor que ya no se presentaba en la interfaz de usuario. Esto puede ser molesto, hasta e incluir un error fatal en el código de la aplicación si no existe una programación defensiva adecuada en el código.

Las tablas de referencias deben incluir al menos 7 columnas:

• Clave principal (cadena o int, pero prefiero cadena en este caso)
• Fecha en que este registro se convirtió en una elección válida
• Fecha en que este registro quedó obsoleto
• Quién creó el registro
• Cuando fue creado
• Quién actualizó el registro por última vez
• Cuándo se actualizó por última vez

Una columna de "descripción" opcional podría ser una buena manera de registrar por qué se creó el registro en primer lugar.

Las claves externas de otras tablas de regreso a la tabla de referencia garantizan que su enumeración en el nivel de aplicación tenga una representación válida en el nivel de datos. Las fechas de inicio y finalización de cada registro dan una indicación clara sobre si cada uno de esos valores de enumeración está actualmente en uso o si han quedado obsoletos. Esto ayuda al crear informes o consultas SQL ad-hoc, porque sabe que tiene un registro en una tabla con algún tipo de información adicional sobre el uso comercial de ese registro.

Recuerda que las cosas cambian. Hombre y mujer parecen conceptos bastante sólidos como una roca, pero las normas sociales cambian. Lo que solía verse como una opción binaria se está expandiendo en algunos países y culturas. Se podrían agregar nuevos valores. Los valores antiguos pueden quedar obsoletos. Una tabla de referencia le brinda una manera de restringir sus opciones actuales, así como de mantener un registro histórico de las elecciones pasadas que solían ser válidas, pero que ya no lo son.

---

Anexo: Para hacer del género un concepto aún más confuso, cada persona individual puede identificarse con varios géneros a la vez. Los campos de la medicina necesitan saber con qué género nació, porque puede marcar una diferencia en la atención médica. Es posible que otros casos de uso solo necesiten conocer una preferencia.

Consulte ¿Existe un estándar de la industria para el modelo de género que no sea masculino y femenino?