Czy konieczne jest utworzenie bazy danych z jak najmniejszą liczbą tabel

52

Czy powinniśmy stworzyć strukturę bazy danych z minimalną liczbą tabel?

Czy powinien być zaprojektowany w taki sposób, aby wszystko pozostawało w jednym miejscu, czy też jest w porządku mieć więcej stołów?

Czy to i tak wpłynie na coś?

Zadaję to pytanie, ponieważ mój przyjaciel zmodyfikował strukturę bazy danych w mediaWiki. W końcu zamiast 20 stołów używał tylko 8, a zajęło mu to 8 miesięcy (to było jego zadanie na studia).

EDYTOWAĆ

Kończę odpowiedź jako: wielkość tabel NIE ma znaczenia, dopóki sprawa nie będzie wyjątkowa; w takim przypadku denormalizacja może pomóc.

Dziękujemy wszystkim za odpowiedzi.

Shaheer
źródło
15
Minimalna liczba tabel jest łatwa, wystarczy serializować całość do master_table (nazwa_tabeli, nazwa_kolii, typ_kola, identyfikator_wiersza, wartość).
Inca
co? nie
rozumiem
12
Ponieważ każde pole w bazie danych jest zdefiniowane przez kombinację nazwy tabeli, nazwy kolumny, klucza podstawowego i wartości, zawsze można zmniejszyć liczbę tabel, denormalizując je w pojedynczą tabelę, która właśnie to przechowuje. Niezbyt przydatne, ale całkowicie możliwe.
Inca
Cóż, prosiłem o wiedzę, a jeśli coś jest mniej przydatne niż istniejące, po co zawracać sobie tym głowę? mam na myśli, czy da to jakąkolwiek poprawę? wydajność na przykład?
Shaheer
1
@Hamza: Może zapewnić lepszą wydajność. To naprawdę zależy od konkretnych okoliczności. Nie ma tu prawie wystarczających informacji, aby udzielić konkretnej odpowiedzi.
FrustratedWithFormsDesigner

Odpowiedzi:

155

Zignoruj liczbę tabel. Martw się więcej o poprawianie projektu . Jeśli głównym problemem jest ilość tabel, prawdopodobnie nie powinieneś projektować systemów baz danych.

Jeśli twój przyjaciel potrzebował tylko 8 tabel, a system działa dobrze, to 8 to poprawna liczba, a pozostałe 12 może nie być konieczne do tego, co robił.

Możliwymi wyjątkami mogą być specyficzne środowiska, które mają twarde ograniczenia dotyczące liczby tabel, ale nie mogę wymyślić konkretnego przykładu takiego systemu poza szczytem mojej głowy.

FrustratedWithFormsDesigner
źródło
107
+1:If your major concern is quantity of tables, you should probably not be designing database systems.
Joel Etherton,
9
Następstwo: tabela bazy danych nie zajmuje [dużo] dodatkowego miejsca. To dane zajmują miejsce. Normalizacja = więcej tabel = mniej powtórzeń = mniej miejsca. Próbując zminimalizować liczbę stołów, nie tylko kompromitujesz projekt, faktycznie marnujesz miejsce . Ten „golf stołowy” jest po prostu zły, chyba że niektóre stoły są dosłownie zbędne.
Aaronaught
1
+1, choć nie sądzę, że wiemy wystarczająco dużo, aby powiedzieć, że poprawna liczba to 8 w jego przypadku, ponieważ nie możemy porównać schematów (oryginał może lepiej wytrzymać wyższy wolumen transakcji niż obecnie aplikacja, ponieważ przykład)
Adam Robinson,
2
@Hamza: Ok, więc może mieć dobre umiejętności PHP i dobre umiejętności bazodanowe, a ten projekt może wymagać obu - ale nie zakładaj, że posiadanie jednego automatycznie implikuje drugie. Wielu programistów może posiadać jedną umiejętność, ale nie drugą.
FrustratedWithFormsDesigner
4
@Tom Anderson - W takim razie nadal nie powinieneś projektować systemów baz danych.
Joel Etherton,
71

Baza danych powinna mieć dokładnie tyle tabel, ile potrzebuje. Nie mniej, nie więcej.

Adam Crossland
źródło
3
polish.stackexchange.com/questions/495/less-vs-fewer Nie zamieniaj tego w dyskusję, ale oto ciekawa dyskusja na temat debaty „mniej” vs. „mniej”, w tym jej początków, z English Language SE , ponieważ wydaje się, że was to zachwyca;)
Corey,
17

Tabele bazy danych powinny być zgodne z zasadą pojedynczej odpowiedzialności, podobnie jak klasy. Każda tabela powinna zajmować się nie więcej niż jedną grupą powiązanych danych na początek. Pomijając wydajność, sprawia to, że łatwiej jest zarządzać całą bestią, ponieważ same stoły będą mniejsze. Zapewnia to również lepszą wydajność, ponieważ mniejsze tabele szybciej wyszukują i dołączają.

Nie martw się o liczbę tabel bardziej niż o liczbę klas - nie martw się wcale. Skoncentruj się na tworzeniu dobrego, czystego, czytelnego kodu, a nie na tym, ile zajmuje ono miejsca. Refaktycznie agresywnie, gdy masz już działający produkt, aby go ulepszyć - mam na myśli również bazę danych! Zobaczysz kolumny, które powinny znajdować się w innych tabelach lub nie są potrzebne itp. Profil, aby zobaczyć, które zapytania zajmują najwięcej czasu i dlaczego, i rozwiązać te problemy, jeśli naprawdę są problemem.

Michael K.
źródło
4
W znormalizowanym modelu danych tak jest to najlepsze podejście, jednak jeśli baza danych jest przeznaczona do raportowania lub przede wszystkim dostępu do odczytu, wówczas zdenormalizowane „spłaszczone” tabele będą działać lepiej na dużych zestawach danych. Mniejsza liczba tabel w tym przypadku spowoduje mniej połączeń i lepszą wydajność.
wałek klonowy
2
@maple Absolutnie się zgadzam. Musisz się profilować, aby ustalić, które zestawy danych należy pogrupować, więc IMO musisz zacząć znormalizować. YMMV, eksperci zapewne potrafią to zrzucić z głowy :) Jeff ma post o denormalizacji, że może cię też zainteresować.
Michael K
1
Dobry i pomocny post, już go przeczytałem! Czasami możesz wykorzystać to, co najlepsze z obu światów. Jeśli raportowanie nie musi odbywać się w 100% w czasie rzeczywistym, należy zachować dwa schematy, jeden główny schemat jest transakcyjnym znormalizowanym schematem do użytku aplikacji, a drugi schemat znormalizowany, który jest regularnie przesyłany strumieniowo i dostosowany do raportowania dostępu do danych.
wałek klonowy
1
Więcej informacji na ten temat z wyjaśnieniem schematu gwiezdnego
wałek klonowy
1
@maple_shaft, zgadzam się, że baza danych raportowania jest często denominowana pod względem wydajności, ale nie są czymś, czego oczekiwałbym od studenta lub młodszego programisty. Wiem, że na pewno nie pozwolę na obsługę moich hurtowni danych przez nikogo, kto nie miałby sprawdzonej wiedzy.
HLGEM,
7

Produkcyjna baza danych dla aplikacji biznesowej może zawierać setki, a nawet tysiące tabel. Potrzebujesz liczby tabel potrzebnych do wymagań biznesowych. Próba zmniejszenia liczby tabel tylko ze względu na mniejszą liczbę tabel zwykle powoduje, że baza danych jest trudniejsza do wyszukania, ma problemy z integralnością danych i jest znacznie trudniejsza w utrzymaniu niż znormalizowana baza danych.

Są chwile, kiedy potrzebna jest denormalizacja. Powinno to zrobić tylko ktoś, kto dokładnie wie, co robi i dlaczego. Mianowanie jest bardzo łatwe, więc powinien to zrobić wyłącznie specjalista ds. Baz danych lub starszy programista aplikacji z wieloletnim doświadczeniem w bazach danych. Niedoświadczona osoba powinna dążyć do osiągnięcia co najmniej trzeciej normalnej formy (chyba że zajmujesz się hurtownią danych, która nie byłaby obszarem, dla którego nie rozważałbym zatrudniania niedoświadczonej osoby) w dowolnej bazie danych, którą zaprojektował.

Kiedy ludzie mówią, że zmniejszają tabele, ponieważ łączenia są drogie, zwykle są ignoranckie lub mają źle zaprojektowane bazy danych, w których brakuje krytycznych indeksów lub używają dużych kluczy z wieloma kolumnami. Relacyjne bazy danych są zaprojektowane do korzystania z połączeń, a połączenia mogą być dość wydajne, jeśli FK są odpowiednio indeksowane i używają małych pól do łączenia (liczby całkowite są najbardziej wydajne). Zauważysz, że dużym firmom, które mają bazy danych wielkości terrabajtów, w jakiś sposób udaje się uzyskać doskonałą wydajność i korzystać z połączeń.

Żaden poważny projektant bazy danych nigdy nie próbuje zmniejszyć liczby tabel tylko dlatego, że chce mniej tabel. Zmniejszasz liczbę tabel, ponieważ dane nie są już potrzebne lub masz problem z wydajnością, którego nie możesz rozwiązać w żaden inny sposób (i istnieje wiele sposobów wypróbowania przed podjęciem dużego ryzyka związanego z denormalizacją tabeli) .

HLGEM
źródło
Google zaprojektował BigTable i celowo wykluczył łączenia, ponieważ nie można go zrównoleglać.
Lie Ryan,
2
@Lie Ryan, BigTable to szczególny przypadek, który NIE jest odpowiedni dla większości aplikacji biznesowych, ponieważ integralność danych nie stanowi wielkiego problemu. Google nie potrzebuje wielu skomplikowanych reguł biznesowych do wyszukiwania. Założę się, że ich korporacyjna aplikacja finansowa nie korzysta z BigTable. Niemniej jednak większość aplikacji biznesowych, które mają duże bazy danych, mogą w rzeczywistości używać sprzężeń i działać dobrze, jeśli projektant jest kompetentny. Korporacyjne bazy danych mają wiele sposobów na poprawę wydajności (w tym partycjonowanie), dzięki czemu nie trzeba tracić funkcji integralności danych relacyjnej bazy danych.
HLGEM,
+1 dla Ciebie, @HLGEM, zarówno za odpowiedź, jak i komentarz; wstydem jest widzieć wielu programistów, którzy wskakują na modowe bazy danych dokumentów, ponieważ myślą, że „dołącza = powoli”, tylko po to, aby przejść i spróbować rozwiązać problemy relacyjne, które zostały rozwiązane przez relacyjne bazy danych 20 lat temu.
Adam Robinson
5

Ponieważ każde pole w bazie danych jest zdefiniowane przez kombinację nazwy tabeli, nazwy kolumny, klucza podstawowego i wartości, zawsze można zmniejszyć liczbę tabel, denormalizując je w pojedynczą tabelę, która przechowuje właśnie to. Niezbyt przydatne, ale całkowicie możliwe.

Tabele to abstrakcyjna warstwa, która pomaga w problemach z danymi. Właśnie dlatego są tworzone. Zrobiłem z tego żart, ale zrozumienie, że możesz zredukować każdy zestaw danych do jednej tabeli głównej, natychmiast wskazuje, dlaczego nie powinieneś: ponieważ tabele coś ci przynoszą. Na poziomie koncepcyjnym przynoszą Ci strukturę łatwiejszą do zrozumienia dla ludzi niż dane serializowane. Na poziomie pośrednim wprowadzają koncepcję normalizacji: aby uniknąć zapisywania zbędnych danych i dać jeden punkt na zmiany, zamiast zmieniać coś w kilku miejscach. Na poziomie technicznym bazy danych przynoszą większość rzeczy, które chcesz robić z danymi, liczne narzędzia, a także wdrażały je i testowały więcej niż prawdopodobnie sam. Pomyśl o typach danych, wartościach domyślnych, prawach użytkownika, indeksach, ograniczeniach klucza obcego itp. Został przetestowany, używany przez wielu, zoptymalizowany, debugowany. (Nie do perfekcji, ale nadal.)

Ponieważ baza danych jest narzędziem, najważniejsze jest podjęcie decyzji o sposobie korzystania z tego narzędzia. Liczba tabel nie jest ważna. Minimalizacja jest zawsze możliwa, ale kosztem wyrzucenia korzyści. (Jeśli przeczytasz więcej o normalizacji, natkniesz się na kilka przypadków denormalizacji - ale nawet wtedy chodzi o właściwe decyzje, a nie tylko ślepą redukcję liczby tabel).

Inka
źródło
dzięki, to jest dużo jasne teraz !, a ja już przeczytać o normalizacji btw, to zrobię to nawet w bazach CakePHP, co zachęca innego i nieco innego podejścia.
Shaheer
3

Powinieneś użyć odpowiedniej liczby tabel. Teoretycznie można zadowolić się tabelą z pojedynczą tabelą, denormalizując całą bazę danych, ale baza danych byłaby bezużyteczna. Twój przyjaciel brzmi, jakby miał za dużo czasu na rękach.

Neil Butterworth
źródło
2

Posiadanie minimalnej liczby stołów wydaje mi się bardzo osobliwym celem.

Z pewnością zmniejszenie schematu z 20 tabel do 8 może być dobrą rzeczą (jeśli zostanie wykonane dobrze, może zmniejszyć sprzężenia i zwiększyć wydajność, usunąć nieużywane kolumny itp.), Ale może również utrudnić zrozumienie i usprawnienie dalszego działania.

Jeśli pomyślisz o tym w inny sposób, czy Twoim zdaniem normalizacja jest dobra? Normalizacja zwykle prowadzi do większej liczby tabel, ale także prowadzi do łatwiejszych w utrzymaniu rozwiązań, zmniejszonego powielania danych i łatwiejszego zarządzania danymi.

Oczywiście może to również prowadzić do obniżenia wydajności (przy założeniu, że zdenormalizowana baza danych została dobrze zaprojektowana).

Ostatecznie musisz pomyśleć o swoich wymaganiach w tych obszarach, ale jako domyślną pozycję początkową powiedziałbym, aby przejść na rozsądny poziom normalizacji, a następnie sprawdzić, czy powoduje to określone problemy, w przypadku których mniej tabel może być rozwiązaniem.

Jon Hopkins
źródło
0

Liczba nie jest ważna. Projekt jest. Spójrz na niektóre systemy tam. Magento, PHPBB itp. Mają dziesiątki tabel w swoich systemach i działają dobrze.

Ryan Street
źródło
0

Oprócz obaw związanych z normalizacją i wydajnością możesz użyć „wymagającego innej tabeli” jako sposobu zarządzania zakresem aplikacji. Ta funkcja będzie wymagała nowego stołu i cały czas, energii i wysiłku, aby projektować, budować, testować, zarządzać aktualizacjami i inne związane z tym kodowanie. Dodanie 5 pól do istniejących tabel (w stosownych przypadkach) jest znacznie łatwiejsze niż tabeli 5 kolumnowej.

JeffO
źródło
0

Jeśli projektujesz bazę danych, starając się zminimalizować tworzenie tabel, wkrótce zobaczysz nagłą trudność i błądzisz na swój sposób.

Podczas tworzenia projektu bazy danych liczba tabel nie powinna znajdować się na pierwszym planie. Umieść rzeczy tam, gdzie potrzebują, aby logicznie i relatywnie iść.


źródło
0

Myślę, że liczba tabel ma znaczenie i może mieć duży wpływ na wydajność, jeśli zdecydujesz się podzielić dane, które powinny, ze względu na wszystkie intencje i cele biznesowe, pozostać razem, w wielu tabelach (tj. Abyś miał znormalizowaną bazę danych). Zwykle, gdy to zrobisz, będziesz zmuszony do JOIN Operations (lub odpowiednika innego niż SQL), aby uzyskać wszystkie potrzebne dane, a dla wystarczająco dużych tabel o takiej strukturze, wydajność gwałtownie spada.

Nie będę wdawał się w szczegóły, ale myślę, że bardzo prawdziwy fakt, że liczba tabel może wpływać na wydajność, jest jednym z powodów, dla których nie wymyślono baz danych noSQL, takich jak Cassandra, Mongo i Google BigTable (sic!), i dlatego też zachęcają do normalizacji danych (a tym samym do unikania dużej liczby tabel / kolekcji itp.).

To samo można powiedzieć o serwerach wyszukiwania, takich jak Solr Apache, który tak naprawdę nie zachęca ani nie ułatwia dzielenia dokumentów na wiele „tabel” lub „typów wpisów”, zachęcając do posiadania schematu „jeden obejmuje wszystkie”, który ma wspólne pola do wszystkich typów dokumentów, które chcesz indeksować (i w konsekwencji unikaj wykonywania operacji typu JOIN).

Nie twierdzę, że sam fakt posiadania tabel x w schemacie niekoniecznie sprawi, że będzie on wolniejszy niż schemat z tabelami x / 2 przez cały czas, ale istnieją pewne konteksty, w których może prowadzić do spowolnienia z powodu konsekwencji dodatkowe operacje potrzebne do agregacji danych we wszystkich tych tabelach. Kontynuując to, nie sądzę też, że można powiedzieć „dowolna liczba tabel i ekstremalna normalizacja danych nie ma żadnego wpływu na wydajność”.

Shivan Dragon
źródło
0

Wujek Bob twierdzi, że More jest prostsze.

Zobacz http://c2.com/cgi/wiki?FearOfAddingTables

„dobry projekt jest ogólnie uproszczony poprzez dodanie tabel”

Uważam, że prawie wszystkie byty są wiele do wielu, co wymaga więcej tabel.

Zrób tabelę krajów z kodem kontynentu. Och, nie możesz, bo w rzeczywistości jest 8 krajów transkontynentalnych. To samo dotyczy walut. Panama używa dwóch.

Neil McGuigan
źródło
-2

Zatem odpowiedź brzmi TAK.

Ale zależą od tego, jakie jest prawdziwe znaczenie „minimalnej” liczby tabel.

Na przykład (anty-przykład).

Jeśli mam kolejne obiekty

  1. użytkownicy
  2. klienci

i oba mają te same stany (pola) i wtedy nie ma żadnych ograniczeń bezpieczeństwa, o wiele bardziej nadaje się do zrobienia pojedynczej tabeli

  1. table_persons

raczej dwie różne tabele

  1. table_users
  2. table_customers

minus jest w table_persons będziemy musieli dodać nowe pole (type_of_person).

Innym błędem (błędem, jeśli tak naprawdę nie trzeba tego robić) jest „podzielenie” tabeli, odczytanej jako: rozdzielenie jednej tabeli na dwie części.

  1. table_persons

w dwóch tabelach

  1. table_info_persons
  2. table_extra_info_persons

ponieważ zmuszasz się do niektórych zapytań, aby połączyć dwie tabele i jest źle.

magallanes
źródło
hej twoja odpowiedź jest bardzo opisowa i pomaga, dzięki
Shaheer,
2
To daje mi retrospekcje do mojej pierwszej aplikacji korporacyjnej i bazy danych za nią oraz koszmaru, jaki DBA sprawiło, że był nazistowskim stołem na takie rzeczy. Absolutnie nigdy nie trzymałbym klientów i użytkowników, którzy są całkowicie odmiennymi podmiotami gospodarczymi.
-1: Użytkownicy i klienci mają różne pola; Jeśli nie w tym momencie, będą mieli to w przyszłości. Zasługują więc na osobne tabele.
Sjoerd,
1
@Sjoerd, @Chris: Chociaż często tak jest, niekoniecznie jest to prawda. Takie rzeczy są zależne od aplikacji. Biorąc to pod uwagę, zgadzam się z sentymentem. Zbyt często programiści baz danych widzą „wspólne nazwy pól”, co oznacza, że ​​są to te same dane. Staje się to szczególnie łatwe, gdy najpierw spojrzysz na bazę danych z ORM (innymi słowy, wstecz). Podczas gdy koncepcje OO można modelować w bazie danych, bazy danych są wierszami i relacjami, a nie obiektami .
Adam Robinson
1
+1 dla „baz danych to wiersze i relacje, a nie obiekty”, dodam je do moich ulubionych cytatów!
Shaheer