Plusieurs à plusieurs relation

Question

J'ai un clients et des gestionnaires, deux tables indépendamment. Ma table client contient près de 100 millions d'enregistrements alors que la table des gestionnaires contient 100 enregistrements. Maintenant, je suis en mesure de cartographier les clients au gestionnaire. Les règles sont les suivantes

1. Un gestionnaire peut avoir plusieurs clients.
2. Un client peut être mappé avec plusieurs gestionnaires.

Quel est le meilleur DB Design pour résoudre ce problème? Créer une capacité ManagerCustomerMapping est une idée. Mais je ne suis pas content avec ça. à cause de cela, me conduire une très grande table. Par exemple. Si Manager1 et Manager2 sont mappés avec tous les clients, alors cette table a deux cent millions d'enregistrements.

Answer 1

La meilleure conception de DB, malgré vos doutes, est exactement ce que vous avez décrit. En d'autres termes, avoir une table de mappage ManagerCustomerMapping.

Toujours Commencez par 3NF et modifiez si et seulement si de réels problèmes de performances ne peuvent pas être résolus autrement. Si votre entreprise est aussi grande qu'elle en a l'air (avec 100 millions de clients), le stockage sur disque ne devrait pas poser de problème, et une indexation appropriée de la table de mappage devrait atténuer les problèmes de performances.

Et oui, si chaque client correspond à deux gestionnaires différents, vous aurez 200 millions d'enregistrements. Ce n'est pas un problème. Dans le genre de magasins où je travaille (DB2 on System z), il s'agit d'une table de taille moyenne.

La beauté de SQL est que vous pouvez généralement échanger un SGBD s'il ne fonctionne pas assez bien. Deux cent millions de lignes de deux colonnes d'ID ne seraient pas onéreuses pour la base de données moyenne, et c'est la meilleure façon de procéder, en particulier s'il y a la possibilité qu'un client ne soit pas affecté à un gestionnaire (ou vice versa). Toute autre solution qui essaie de placer un ID client dans la table du gestionnaire (ou un ID de gestionnaire dans la table client) gaspillera de l'espace dans ce cas.

Answer 2

Vos chiffres sont assez intrigants. Combien de clients un gestionnaire de compte peut-il connaître? Combien de managers avez-vous, 1M? Un vendeur serait-il une meilleure description? Si oui, peut-être vous devriez envisager l'approche, par exemple des entrepôts de données (DW) une étoile Kimball ressemblerait à ceci:

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, ..) 

Le tableau factSales pourrait capturer des ventes de chaque article, il est vrai grande table, mais vous avez pas besoin Pour établir une correspondance entre les clients et les gestionnaires, il suffit de faire une recherche dans la table des faits et de trouver le dernier vendeur ayant eu un contact avec le client. D'une certaine manière, je pense que cela pourrait être plus proche du modèle d'affaires.
Si ce n'est pas un secret, quel type d'entreprise est ce suivi de base de données?

Answer 3

Attendez maintenant. Vous indiquez qu'un gestionnaire peut être affecté à TOUS les clients? Un gestionnaire pourrait être responsable de une centaine de millions de clients? Honnêtement, il semble que quelque chose ne va pas là-bas.

Si vous avez un gestionnaire simple < -> relation client comme décrit, la conception que vous avez décrite (une table de liaison many-to-many) est correcte.Mais si vous voulez vraiment pouvoir relier TOUS les clients à plusieurs des gestionnaires, je suppose qu'il y a une hiérarchie de gestionnaires dont vous ne nous avez pas parlé - c'est-à-dire qu'un gestionnaire peut gérer d'autres gestionnaires, qui peuvent gérer d'autres managers, qui gèrent ensuite les clients (avec des niveaux supplémentaires possibles et une gestion directe des clients mixée avec la gestion des managers à tous les niveaux).

Vous voyez ce type de structure dans les organisations de marketing à plusieurs niveaux et également dans les systèmes de commission dans certaines industries (je l'ai trouvé dans l'assurance l'autre jour). Si c'est le cas, vous devez exprimer la relation entre les gestionnaires séparément (soit avec une colonne auto-référentielle dans la table des gestionnaires, s'il n'y a qu'un seul gestionnaire parent direct possible pour chaque gestionnaire, ou une table séparée si elle est plusieurs à plusieurs) et seulement relier les clients à leur ultime, directeur direct.