wiele do wielu relacji

Question

Mam klientów i menedżerów, dwie tabele samodzielnie. Mój stół klienta ma prawie sto milionów rekordów, podczas gdy tabela menedżerów ma 100 rekordów. Teraz jestem w stanie mapować klientów do menedżera. Zasady są następujące:

1. Jeden menedżer może mieć wielu klientów.
2. Jeden klient może zostać odwzorowany za pomocą wielu menedżerów.

Jaki jest najlepszy DB Projekt rozwiązać ten problem? Tworzenie zdolnych ManagerCustomerMapping to jeden pomysł. Ale nie jestem z tego zadowolony. z tego powodu doprowadził mnie do bardzo dużego stołu. Na przykład. Jeśli menedżer1 i menedżer2 zmapowały się ze wszystkimi klientami, ta tabela zawiera dwieście milionów rekordów.

Answer 1

Najlepszy projekt DB, mimo swoich obaw, jest dokładnie to, co opisane. Innymi słowy, mieć tabelę mapowania ManagerCustomerMapping.

Zawsze zaczynają się od 3NF i modyfikują wtedy i tylko wtedy, gdy występują rzeczywiste problemy z wydajnością, których nie da się rozwiązać na inne sposoby.

Jeśli Twoja firma jest tak duża, jak wygląda (przy 100 milionach klientów), miejsce na dysku nie powinno stanowić problemu, a właściwe indeksowanie tabeli mapowania powinno złagodzić wszelkie obawy dotyczące wydajności.

I tak, jeśli każdy klient mapy do dwóch różnych menedżerów, trzeba będzie 200 milionów płyt. To nie jest problem. W przypadku sklepów, w których pracuję (DB2 on System z), chodzi o tabelę o średnich rozmiarach.

Piękno SQL polega na tym, że można wymieniać DBMS, jeśli nie działa on wystarczająco dobrze.

dwieście milionów wierszy z dwóch kolumn identyfikacyjnych nie będzie uciążliwy dla przeciętnego bazie danych i jest to najlepsza droga, szczególnie czy istnieje możliwość, że klient nie może zostać przypisane do kierownika (lub vice versa). Każde inne rozwiązanie, które próbuje umieścić identyfikator klienta w tabeli menedżera (lub identyfikator menedżera w tabeli klienta), spowoduje marnowanie miejsca w tym przypadku.

Answer 2

Twoje numery są dość intrygujące. Ilu klientów może znać menedżer konta - 100? Ilu menedżerów posiadasz, 1M? Czy sprzedawca byłby lepszym opisem? Jeśli tak, to może warto rozważyć podejście hurtowni danych (DW), na przykład gwiazdy Kimball wyglądałby następująco:

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

tabela factSales by uchwycić sprzedaży każdej pozycji, co prawda duży stół, ale nie musiałby aby w ogóle mapować klientów do menedżerów, wystarczy przejrzeć tabelę faktów i znaleźć ostatniego sprzedawcę, który kontaktował się z klientem. Jakoś myślę, że to może być bliższe modelowi biznesowemu.
Jeśli nie jest tajemnicą, jaki rodzaj działalności polega na śledzeniu bazy danych?

Answer 3

Teraz trzymaj się. Twierdzisz, że menedżer może zostać przypisany do WSZYSTKICH klientów? Menedżer może być odpowiedzialny za sto milionów klientów? Szczerze mówiąc, wygląda na to, że coś jest nie tak.

Jeśli masz prostego menedżera < -> relacje z klientem zgodnie z opisem, to opisany przez ciebie projekt (tabela łączenia wielu do wielu) jest poprawny.Ale jeśli naprawdę chcesz mieć możliwość połączenia WSZYSTKICH klientów z kilkoma menedżerami, domyślam się, że istnieje hierarchia menedżerów, o których nam nie powiedziałeś - to znaczy, że menedżer może zarządzać innymi menedżerami, którzy mogą zarządzać pozostałymi menedżerami, którzy następnie zarządzają klientami (z możliwymi dodatkowymi poziomami i bezpośrednim zarządzaniem klientami w połączeniu z zarządzaniem menedżerami na dowolnym poziomie).

Widzisz tego rodzaju strukturę w wielopoziomowych organizacjach marketingowych, a także w systemach prowizji w niektórych branżach (właśnie zdarzyło mi się natknąć na to w ubezpieczeniach na drugi dzień).

Jeśli tak jest, musisz wyrazić relację między menedżerami osobno (z kolumną z samowystarczalnością w tabeli menedżerów, jeśli jest tylko jeden bezpośredni menedżer nadrzędny dla każdego menedżera lub oddzielna tabela, jeśli jest wielu do wielu) i tylko łączą klientów z ich bezpośrednim, bezpośrednim menedżerem.