El problema aquí es subtipificar . Existen tres enfoques básicos para tratar con los subtipos.
- Coloque cada tipo de registro en una tabla completamente separada;
- Coloque un registro en una tabla principal y luego un registro en una tabla de subtipo; y
- Coloque todos los registros en una tabla, con columnas anulables para los datos "opcionales" (es decir, cosas que no se aplican a ese tipo).
Cada estrategia tiene sus méritos.
Por ejemplo, (3) es particularmente aplicable si hay poca o ninguna diferencia entre los diferentes subtipos. En su caso, ¿los diferentes registros de registro tienen columnas adicionales si son de un tipo en particular? Si no lo hacen o hay pocos casos en los que lo hacen, ponerlos todos en una tabla tiene mucho sentido.
(2) se usa comúnmente para una mesa Party. Este es un modelo común en los CRM que involucra un objeto Parte principal que tiene subtipos para Persona y Organización (La organización también puede tener subtipos como Compañía, Asociación, etc.). Persona y Organización tienen diferentes propiedades (p. ej., saludo, nombre de pila, fecha de nacimiento, etc. para Persona), por lo que tiene sentido dividir esto en lugar de usar columnas anulables.
(2) es potencialmente más eficiente en el uso del espacio (aunque la sobrecarga de las columnas NULL en los DBMS modernos es muy baja). El problema más grande es que (2) podría ser más confuso para los desarrolladores. Obtendrá una situación en la que alguien necesita almacenar un campo adicional en algún lugar y lo colocará en una columna que está vacía para ese tipo simplemente porque es más fácil hacerlo que obtener la aprobación de los DBA para agregar una columna (no, no estoy bromeando ).
(1) es probablemente el esquema menos utilizado de los 3 en mi experiencia.
Por último, se debe considerar la escalabilidad y es probablemente el mejor caso para (1). En ciertos puntos, los JOIN no se escalan de manera efectiva y deberá usar algún tipo de esquema de partición para reducir el tamaño de las tablas. (1) es un método para hacerlo (pero un método tosco).
Aunque yo no me preocuparía demasiado por eso. Por lo general, necesitará llegar a cientos de millones o miles de millones de registros antes de que eso se convierta en un problema (a menos que sus registros sean realmente grandes, en cuyo caso sucederá antes).
