Mamy scenariusz czasu projektowania bazy danych SQL Server. Musimy przechowywać dane o różnych organizacjach w naszej bazie danych (np. Klient, dostawca, dystrybutor, ...). Wszystkie organizacje diff dzielą ten sam typ informacji (prawie) ... jak dane adresowe, itp ... I będą one odwoływane w innych tabelach (tj. Połączone przez OrgId i musimy szukać OrgName w wielu miejscach różnic)

Widzę dwie opcje:

Tworzymy tabelę dla każdej organizacji, takiej jak OrgCustomer, OrgDistributor, OrgVendor, itd ... wszystkie tabele będą miały podobną strukturę, a niektóre tabele będą miały dodatkowe specjalne pola, takie jak klient ma pole HomeAddress (którego inne tabele Org nie mają ) .. i wzajemnie.

Tworzymy wspólną tabelę OrgMaster i przechowujemy WSZYSTKIE Organy różnicowe w jednym miejscu. Tabela będzie miała pole OrgType, aby rozróżnić typy różnic w Org. Specjalne pola zostaną dołączone do tabeli OrgMaster (tylko odpowiednie rekordy Org będą miały wartości w takich polach, w innych przypadkach będzie to NULL)

Niektóre plusy i minusy # 1:

PROS:

Pomaga w dystrybucji obciążenia podczas uzyskiwania dostępu do danych typu Org, więc uważam, że poprawia to wydajność.Zapewnia pełny zakres przyzwyczajeń do konkretnej tabeli Org bez wpływu na inne istniejące typy Org.Nie jestem pewien, czy indeksy diff w tabelach diff / rozproszonych działają lepiej niż jedna duża tabela.

CONS:

Replikacja projektu. Jeśli muszę zwiększyć rozmiar pola ZipCode - muszę to zrobić we WSZYSTKICH tabelach.Replikacja w implementacji manipulacji (tj. Użyliśmy procedur przechowywanych dla operacji CRUD, więc replikacja idzie n-krotnie. 3-4 Inert SP, 2-3 SELECT SP, itd ...)Wszystko rośnie n-krotnie od ograniczeń DB do indeksowania SP do obiektów biznesowych w kodzie aplikacji.Zmianę (wspólną) w jednym miejscu należy również wykonać we wszystkich innych miejscach.Niektóre plusy i minusy # 2:

PROS:

N-krotne staje się 1-krotne :-)Konserwacja staje się łatwa, ponieważ możemy spróbować wdrożyć pojedyncze punkty wejścia dla wszystkich operacji (tj. Pojedyncza SP do obsługi operacji CRUD itp.)Musimy się martwić o utrzymanie jednego stołu. Indeksowanie i inne optymalizacje są ograniczone do pojedynczej tabeli.

CONS:

Czy tworzy wąskie gardło? Czy można nim zarządzać, wdrażając widoki i inną zoptymalizowaną strategię dostępu do danych?Druga strona scentralizowanej implementacji polega na tym, że pojedyncza zmiana musi zostać przetestowana i zweryfikowana we WSZYSTKICH miejscach. To nie jest abstrakcyjne.Projekt może wydawać się nieco mniej „zorganizowany” z powodu tych kilku Orgów, dla których musimy dodać „specjalne” pola (które nie mają znaczenia dla innych tabel)

Przypomniałem sobie również opcję # 3 - trzymaj tabele Org osobno, ale stwórz wspólną tabelę OrgAddress do przechowywania wspólnych pól. Ale to sprawia, że ​​jestem w środku # 1 i # 2, co powoduje jeszcze większe zamieszanie!

Szczerze mówiąc, jestem doświadczonym programistą, ale nie jestem równie doświadczonym DBA, ponieważ nie jest to moja praca w głównym nurcie, więc pomóż mi uzyskać właściwy kompromis między parametrami, takimi jak złożoność projektu i wydajność.

Z góry dziękuję. Zachęcamy do zadawania pytań technicznych i sugestii.

Hemant