Co jest bardziej wydajne: wiele tabel MySQL czy jedna duża tabela?

Łączenie tabel nazywa się denormalizacją.

Może (lub nie) pomóc sprawić, aby niektóre zapytania (które sprawiają, że wiele JOINs) działały szybciej kosztem stworzenia piekła konserwacji.

MySQL może używać tylko metody JOIN, czyli NESTED LOOPS.

Oznacza to, że dla każdego rekordu w tabeli driving, MySQL lokalizuje pasujący rekord w tabeli driving w pętli.

Zlokalizowanie rekordu jest dość kosztowną operacją, która może trwać kilkadziesiąt razy dłużej niż czyste skanowanie rekordów.

Przeniesienie wszystkich rekordów do jednej tabeli pomoże Ci pozbyć się tej operacji, ale sama tabela staje się większa, a skanowanie tabeli trwa dłużej.

Jeśli masz wiele rekordów w innych tabelach, to zwiększenie skanowania tabeli może spowodować nadwagę korzyści z rekordów skanowanych sekwencyjnie.

Czy wszystkie są związkami 1:1? Chodzi mi o to, że jeśli użytkownik może należeć do, powiedzmy, różnych poziomów użytkowników lub jeśli zainteresowania użytkowników są reprezentowane jako kilka rekordów w tabeli zainteresowań użytkowników, natychmiast nie wchodzi w grę łączenie tych tabel.

Jeśli chodzi o poprzednie odpowiedzi na temat normalizacji, należy powiedzieć, że reguły normalizacji bazy danych całkowicie pominęły wydajność i przyglądają się tylko temu, co jest schludnym projektem bazy danych. To jest często to, co Ty chcesz osiągnąć, ale są chwile, w których sensowne jest aktywne denormalizowanie w dążeniu do wydajności.

Podsumowując, pytanie sprowadza się do tego, ile pól znajduje się w tabelach i jak często są one dostępne. Jeśli aktywność użytkownika często nie jest zbyt interesująca, może to być po prostu uciążliwe, aby zawsze mieć ją na tym samym rekordzie, ze względu na wydajność i ze względów konserwacyjnych. Jeśli niektóre dane, jak ustawienia, są dostępne bardzo często, ale po prostu zawiera zbyt wiele pola, może też nie być wygodne łączenie tabel. Jeśli zależy Ci tylko na wzroście wydajności, możesz rozważyć inne metody, takie jak oddzielenie ustawień, ale zapisanie ich w zmiennej sesji, dzięki czemu nie musisz często pytać o nie bazy danych.

Czy Wszystkie z tych tabel mają 1-to-1 związek? Na przykład, czy każdy wiersz użytkownika będzie miał tylko jeden odpowiadający mu wiersz w user_stats lub user_levels? Jeśli tak, to może mieć sens połączenie ich w jedną tabelę. Jeśli związek nie jest 1 to 1 chociaż prawdopodobnie nie miałoby sensu łączenie ich (denormalizacja).

Mając je w oddzielnych tabelach vs. jeden stół prawdopodobnie będzie miał niewielki wpływ na wydajność choć chyba że masz setki tysięcy lub miliony rekordy użytkowników. Jedynym prawdziwym zyskiem, który otrzymasz, jest uproszczenie zapytań poprzez ich połączenie.

ETA:

Jeśli Twoja troska dotyczy zbyt dużej liczby kolumn , pomyśl o Jakie rzeczy zwykle używasz razem i połącz je , pozostawiając resztę w osobnej tabeli (lub kilku osobnych tabel, jeśli zajdzie taka potrzeba).

Jeśli spojrzysz na sposób, w jaki używasz danych, domyślam się, że odkryjesz, że coś w rodzaju 80% zapytań używa 20% tych danych pozostałe 80% danych jest wykorzystywane tylko sporadycznie. Połącz to często używane 20% W jeden stół, i zostaw 80%, które nie są często używane w oddzielnych tabelach, a prawdopodobnie będziesz miał dobry kompromis.

Dlaczego nie użyć tego samego podejścia WordPress robi, mając tabelę użytkowników z podstawowymi informacjami o użytkownikach, które każdy ma, a następnie dodając tabelę "user_meta", która może być w zasadzie dowolną parą kluczy, wartości powiązaną z identyfikatorem użytkownika. Więc jeśli chcesz znaleźć wszystkie meta informacje dla użytkownika, możesz po prostu dodać to do zapytania. Nie zawsze będziesz musiał dodawać dodatkowe zapytanie, jeśli nie jest to potrzebne do takich rzeczy, jak logowanie. Korzyści płynące z tego podejścia pozostawia również stół otwarty na dodawanie nowych funkcje dla użytkowników, takie jak przechowywanie ich uchwyt twitter lub każdego indywidualnego zainteresowania. Nie będziesz też musiał radzić sobie z labiryntem powiązanych identyfikatorów, ponieważ masz jedną tabelę, która reguluje wszystkie metadane i ograniczysz ją do tylko jednego skojarzenia zamiast 50.

Wordpress robi to specjalnie, aby umożliwić dodawanie funkcji za pomocą wtyczek, dzięki czemu Twój projekt będzie bardziej skalowalny i nie będzie wymagał całkowitego remontu bazy danych, jeśli chcesz dodać nową funkcję.

Tworzenie jednej masywnej tabeli jest sprzeczne z zasadami relacyjnej bazy danych. Nie połączyłbym ich wszystkich w jeden stół. Masz zamiar uzyskać wiele instancji powtarzających się danych. Jeśli na przykład twój użytkownik ma trzy zainteresowania, będziesz miał 3 Wiersze z tymi samymi danymi użytkownika, aby zapisać trzy różne zainteresowania. Definitywnie przejdź do podejścia wielu "znormalizowanych" tabeli. Zobacz to strona Wiki dla normalizacji bazy danych.

Edit: Zaktualizowałem swoją odpowiedź, tak jak ty zaktualizowałem twoje pytanie... Zgadzam się z moją początkową odpowiedzią jeszcze bardziej teraz...

Duża część tych komórek to prawdopodobnie pozostanie pusty

Jeśli na przykład użytkownik nie miał żadnych zainteresowań, jeśli normalizujesz, to po prostu nie będziesz miał wiersza w tabeli zainteresowań dla tego użytkownika. Jeśli masz wszystko w jednej ogromnej tabeli, będziesz miał kolumny (i najwyraźniej wiele z nich), które zawierają tylko NULL.

Pracowałem w firmie telefonicznej, gdzie było mnóstwo tabel, uzyskanie danych może wymagać wielu złączeń. Gdy wydajność odczytu z tych tabel była krytyczna, wtedy procedury, w których utworzono, które mogłyby generować płaską tabelę (tj. tabelę denormalizowaną), która nie wymagałaby połączeń, obliczeń itp., na które raporty mogłyby wskazywać. Są one następnie używane w połączeniu z agentem SQL server do uruchamiania zadania w określonych odstępach czasu(tj. tygodniowy widok niektórych statystyk byłby uruchamiany raz w tygodniu i tak dalej).

Myślę, że to jedna z tych sytuacji "to zależy". Posiadanie wielu tabel jest czystsze i prawdopodobnie teoretycznie lepsze. Ale kiedy musisz dołączyć 6-7 tabel, aby uzyskać informacje o jednym użytkowniku, możesz zacząć przemyśleć to podejście.

Powiedziałbym, że to zależy od tego, co naprawdę oznaczają Pozostałe tabele. Czy user_details zawiera więcej niż 1 więcej / userów i tak dalej. To, jaki poziom normalizacji najlepiej odpowiada twoim potrzebom, zależy od twoich wymagań.

Jeśli masz jedną tabelę z dobrym indeksem, która prawdopodobnie byłaby szybsza. Ale z drugiej strony prawdopodobnie trudniejsze do utrzymania.

Dla mnie wygląda na to, że można pominąć User_Details, ponieważ prawdopodobnie jest to relacja 1 do 1 z użytkownikami. Ale reszta to chyba dużo wiersze na użytkownika?