tabla asociativa "maestra"?

Question

Considere un modelo para hacer coincidir clientes y servicios. Los clientes pueden ser proveedores y consumidores de servicios en varias ocasiones. Los clientes pueden ser individuos o grupos (empresas), estos últimos tienen contactos múltiples. Los contactos pueden tener varias direcciones, teléfonos, correos electrónicos. Algunas de estas relaciones serán individuales (por ejemplo, servicio al proveedor), pero la mayoría serán de uno a muchos o de muchos a muchos (los contactos múltiples en una empresa tendrían la misma dirección).

En este modelo se suele existir varias tablas asociativas, por ejemplo, client_contact, contract_addr, contact_phone, contact_email, service_provider, service_consumer, etc.

Digamos que emite una consulta simple a la información de contacto para los consumidores de un determinado servicio. Además de las seis tablas de entidades que contienen los datos, las uniones harían referencia a cinco tablas asociativas. Nada particularmente interesante sobre este tipo de consulta, por supuesto, lo hacemos todos los días.

Sin embargo, se me ocurrió: ¿por qué no tener una sola tabla asociativa "maestra" que contenga todas las asociaciones? Se requeriría que esta tabla maestra tenga un "tipo de asociación" además de las dos PK, y que todas las PK sean del mismo tipo (entradas, GUID, etc.).

Por un lado, las consultas se volverían más complicadas porque cada unión necesitaría especificar el tipo y PK. Por otro lado, todas las uniones tendrían acceso a la misma tabla, y con el indexado apropiado y el rendimiento del almacenamiento en caché podría mejorar dramáticamente.

Supuse que podría haber un patrón (o antipatrón) que describa este enfoque, pero que no haya encontrado nada en línea. ¿Alguien lo ha intentado? Si es así, ¿se escala?

Cualquier referencia que pueda proporcionar sería apreciada.

Answer 1

Lo que está describiendo me recuerda las tablas de datos del almacenamiento de datos. Según entiendo, debe comenzar con un esquema transaccional típico con una tabla para modelar cada relación de muchos a muchos. Luego, para reestructurar los datos para facilitar el análisis dimensional, puede agregar algunas/todas las relaciones en su esquema en una tabla ancha donde cada columna es una clave. Esto realiza con eficacia todas las uniones posibles con anticipación y las vuelca en una tabla, invirtiendo el propósito de las combinaciones de consultas de la relación siguiente para llegar a las propiedades de sus entidades.

De todos modos, mi comprensión de estas cosas es nebulosa y mi experiencia efectivamente nula, pero tal vez su idea es una tabla de hechos con otro nombre, lo que los hace útiles para investigar.

Answer 2

En primer lugar, creo que definitivamente está pagando un precio en mantenimiento. Cada vez que tengo una columna de "tipo" como esa, creo que se trata de una bandera roja. Es probable que conduzca a cadenas mágicas en sus procedimientos: debe asegurarse de que el tipo sea consistente en las inserciones y las selecciones, por ejemplo. Por lo tanto, cualquier aumento en el rendimiento debe ser lo suficientemente grande como para justificar este dolor de cabeza.

En segundo lugar, está pagando un precio al almacenar más datos: la columna "tipo" extra para cada asociación. Y luego, estos datos deben recuperarse al ejecutar una consulta, que afecta cuántas filas pueden estar en la memoria a la vez (tal vez).

En tercer lugar, cada consulta probablemente necesite acceder al mismo número total de filas, independientemente de si están almacenadas en varias tablas o en una. Entonces, a menos que sepa algo acerca de sus datos que le permita crear índices agrupados o algo así, probablemente esté recuperando el mismo número de páginas cuando ejecute consultas.

En cuarto lugar, las posibles ganancias de rendimiento provienen de asumir que el índice tiene un comportamiento logarítmico y señalan que 5log (N) es mayor que log (5N), por lo que es mejor usar un índice grande que 5 más pequeños. Sin embargo, la adición de la columna tipo va a reducir este beneficio. No estoy seguro de cómo analizar si lo eliminaría por completo, o simplemente lo reduciría.

En quinto lugar, parece bastante probable que, al menos para algunas consultas, termines uniendo varias copias de esa gran tabla, lo que realmente parece que va a ser un asesino.

Me interesaría ver qué resultados obtienes, pero me sorprendería si hay un beneficio en el rendimiento.

Answer 3

Esto se puede resolver con abstracción y herencia de tablas.

Un cliente individual, cliente de organización, proveedor de servicios son todas las partes que desempeñan funciones.

Una dirección de correo electrónico, número de teléfono, dirección web y dirección física son todas las direcciones.