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

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.

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.

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

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.

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

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

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.

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.

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.

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.

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ść.

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ść”.

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.

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.