Múltiples tablas de intersección vs múltiples uniones
Tengo una relación jerárquica entre mis tablas, y los niños tienen claves externas que se refieren a sus identificadores principales (asumiendo que ides la clave principal para cada tabla):
Departmenttiene muchos Category Groups
Category Grouptiene muchos Category(-ies)
Categorytiene muchos Sub-Category(-ies)
Sub-Categorytiene muchos Attributes.
Ahora, todas estas entidades, excepto las Attributes, son opcionales, lo que significa que si no selecciono nada en mi interfaz de usuario jerárquica en cascada basada en el menú desplegable, necesito mostrar las Attributes que pertenecen a todas las Departments, si solo selecciono una, Departmententonces necesito mostrar Attributes que pertenecen a todos Category Grouplos que pertenecen a eso Departmenty así sucesivamente.
Obviamente, una opción para implementarlo es hacer una unión interna entre todas las tablas para llegar Attribute. Por ejemplo, si no se selecciona nada, será:
Departmentunión Category Group
interna unión Category
interna unión Sub-Category
interna unión interna Attribute
para mostrar todos los atributos que pertenecen a todos los departamentos.
El otro pensamiento en mi cabeza es tener tabla de intersección / relación de proyección (s) -
DepartmentAttributeRelationque tiene las claves externas de Departmenty Attribute,
CategoryGroupAttributeRelationque tiene las claves externas a CategoryGroupy Attributey así sucesivamente.
Esto permitirá la búsqueda directa para llegar a los Attributes dada cualquier entidad.
Mi pregunta es: ¿hay desventajas en el segundo enfoque anterior o existen enfoques mejores para resolver esto?
Respuestas
¿Cuál es el problema con la unión interna? Cree una vista para que no tenga que volver a ver o escribir la desagradable consulta de combinación múltiple.
El primer y más importante inconveniente de la alternativa es que puede tener inconsistencias, es decir, puede tener datos en esas "tablas de unión" que podrían contradecirse, es decir, son posibles las anomalías de inserción. Necesitaría escribir código para evitar que ocurran esas anomalías.
Sin embargo, tenga en cuenta que, a veces, cuando uno cree que una jerarquía siempre tendrá, digamos, 4 niveles de profundidad, surge un requisito cuando se necesita una sub-subcategoría y el diseño de la jerarquía de nivel fijo se rompe. Una solución a prueba de futuro donde puede haber una profundidad desconocida de niveles de jerarquía y solo los elementos "hoja" pueden tener atributos es una cuestión de otra pregunta y otra respuesta.