Relación de muchos a muchos

Question

Tengo clientes y gerentes, dos tablas de forma independiente. Mi tabla de clientes tiene casi cien millones de registros, mientras que la tabla de administradores tiene 100 registros. Ahora estoy en posición de asignar a los clientes al gerente. Las reglas son las siguientes

1. Un gerente puede tener varios clientes.
2. Un cliente puede ser mapeado con múltiples gerentes.

¿Cuál es el mejor diseño de DB para resolver esto? Crear Manage Manager CustomMapping es una idea. Pero no estoy contento con eso. debido a esto, llévame una mesa muy grande. Por ejemplo. Si el Manager1 y el Manager2 se mapearon con todos los clientes, esta tabla tiene 2 cientos millones de registros.

Answer 1

El mejor diseño de base de datos, a pesar de sus dudas, es exactamente lo que usted describió. En otras palabras, tenga una tabla de asignación ManagerCustomerMapping.

Siempre comienzan con 3NF y modifican si y solo si hay problemas reales de rendimiento que no se pueden resolver de otras maneras.

Si su negocio es tan grande como parece (con 100 millones de clientes), el almacenamiento en disco no debería ser un problema, y ​​la indexación adecuada de la tabla de asignación debería mitigar cualquier problema de rendimiento.

Y sí, si cada cliente se asigna a dos administradores diferentes, tendrá 200 millones de registros. Eso no es un problema. En el tipo de tiendas en las que trabajo (DB2 en System z), se trata de una tabla de tamaño mediano.

La belleza de SQL es que en su mayoría puede intercambiar un DBMS si no funciona lo suficientemente bien.

doscientos millones de filas de dos columnas con un diámetro no sería onerosa a la base de datos promedio, y este es el mejor camino a seguir, especialmente si hay la posibilidad de que un cliente no puede ser asignado a un administrador (o vice versa). Cualquier otra solución que intente poner una ID de cliente en la tabla de administrador (o una ID de administrador en la tabla de clientes) desperdiciará espacio en ese caso.

Answer 2

Sus números son bastante intrigantes. ¿Cuántos clientes puede saber un gerente de cuenta - 100? ¿Cuántos gerentes tienes, 1 millón? ¿Sería una persona de ventas una mejor descripción? Si es así, tal vez debería considerar el enfoque de almacenamiento de datos (DW), por ejemplo una estrella Kimball se vería así:

TABLE dimCustomer (KeyCustomer, Name, Address, ...etc) 
TABLE dimSalesPerson (KeySalesPeson, Name, Phone, Area, ...etc) 
TABLE dimProduct (KeyProduct, Description, CatalogPrice, ...etc) 
TABLE dimDate (KeyDate, FullDate, Year, Month, DayOfWeek, IsHoliday, etc...) 
TABLE factSales (KeyCustomer, KeyProduct, KeySalesPerson, KeyDate, Quantity, Ammount, OrderID, ..) 

La tabla factSales capturaría las ventas de cada artículo, es cierto gran mesa, pero no se necesitaría para asignar clientes a los gerentes, simplemente busque en la tabla de hechos y busque la última persona de ventas que tuvo contacto con el cliente. De alguna manera, creo que esto puede estar más cerca del modelo comercial.
Si no es un secreto, ¿qué tipo de negocio es el seguimiento de esta base de datos?

Answer 3

Ahora espera. Usted declara que un gerente podría ser asignado a TODOS los clientes? Un gerente podría ser responsable de cien millones clientes? Honestamente, parece que algo está mal allí.

Si tiene un gestor simple < -> relación con el cliente como se describe, entonces el diseño que describió (una tabla de vinculación de muchos a muchos) es correcto.Pero si realmente desea poder vincular TODOS los clientes con varios de los gerentes, supongo que hay una jerarquía de gerentes de la que no nos ha informado; es decir, un gerente puede administrar a otros gerentes, que pueden Administrar a otros gerentes, quienes luego administran clientes (con niveles adicionales posibles y administración directa de clientes combinada con la administración de gerentes en cualquier nivel).

Ve este tipo de estructura en las organizaciones de mercadotecnia multinivel y también en los sistemas de comisiones en ciertas industrias (el otro día lo encontré en un seguro).

Si ese es el caso, debe expresar la relación entre los gerentes por separado (ya sea con una columna autorreferencial en la tabla de gerentes, si solo hay un administrador primario directo posible para cada gerente o una tabla separada si es muchos a muchos) y solo vinculan a los clientes con su último administrador directo.