Mi consejo sobre el modelado de datos es:
- Debe favorecer las columnas opcionales (que aceptan valores NULL) en lugar de las uniones 1:1 en términos generales . Todavía hay casos en los que 1:1 tiene sentido, generalmente girando en torno a la subtipificación. Las personas tienden a ser más aprensivas cuando se trata de columnas anulables que cuando se trata de uniones extrañas;
- No hagas un modelo también indirecta a menos que realmente justificado (más sobre esto a continuación);
- Favorece las uniones sobre la agregación. Esto puede variar, por lo que debe probarse. Ver Oracle vs MySQL vs SQL Server:Agregación contra uniones para un ejemplo de esto;
- Las uniones son mejores que las selecciones N+1. Una selección N+1 es, por ejemplo, seleccionar un pedido de una tabla de base de datos y luego emitir una consulta separada para obtener todos los elementos de línea para ese pedido;
- La escalabilidad de las uniones es generalmente solo un problema cuando estás haciendo selecciones masivas. Si selecciona una sola fila y luego la une a algunas cosas, rara vez es un problema (pero a veces lo es);
- Las claves externas deben siempre indexarse a menos que se trate de una tabla trivialmente pequeña;
Más en Errores de desarrollo de bases de datos cometidos por desarrolladores de aplicaciones .
Ahora, en cuanto a la franqueza de un modelo, déjame darte un ejemplo. Supongamos que está diseñando un sistema para la autenticación y autorización de usuarios. Una solución sobrediseñada podría verse así:
- Alias (id, nombre de usuario, user_id);
- Usuario (id, ...);
- Correo electrónico (id, user_id, dirección de correo electrónico);
- Iniciar sesión (id, user_id, ...)
- Funciones de inicio de sesión (id, login_id, role_id);
- Rol (id, nombre);
- Privilegio de rol (id, role_id, privilegio_id);
- Privilegio (id, nombre).
Por lo tanto, necesita 6 uniones para pasar del nombre de usuario ingresado a los privilegios reales. Claro que puede haber un requisito real para esto, pero la mayoría de las veces este tipo de sistema se instala debido a que algunos desarrolladores piensan que algún día podrían necesitarlo, aunque cada usuario solo tiene un alias, el usuario para iniciar sesión es 1 :1 y así sucesivamente. Una solución más simple es:
- Usuario (id, nombre de usuario, dirección de correo electrónico, tipo de usuario)
y, bueno, eso es todo. Tal vez si necesita un sistema de roles complejo, pero también es muy posible que no lo necesite y, si lo necesita, es razonablemente fácil de ubicar (el tipo de usuario se convierte en una clave externa en una tabla de roles o tipos de usuarios) o generalmente es sencillo mapear el viejo a lo nuevo.
Esto tiene que ver con la complejidad:es fácil de agregar y difícil de quitar. Por lo general, es una vigilia constante contra la complejidad no intencionada, que ya es bastante mala sin ir y empeorarla al agregar una complejidad innecesaria.
