mysql - ile kolumn to za dużo?

111

Konfiguruję tabelę, która może mieć maksymalnie 70 kolumn. Zastanawiam się teraz nad podzieleniem go, ponieważ niektóre dane w kolumnach nie będą potrzebne przy każdym dostępie do tabeli. Z drugiej strony, jeśli to zrobię, będę musiał używać złączeń.

Czy w którym momencie, jeśli w ogóle, uważa się, że jest za dużo kolumn?

sql mysql Ćwiek
źródło
6
Nie musimy przez cały czas używać SELECT *. Zawsze mamy możliwość wybrania tylko kolumn, które są nam potrzebne w danej sytuacji.
APC
3
70 kolumn ?! Ile z nich nie może być zerowych?
OMG Kucyki
1
Najważniejsze pytanie brzmi: czy normalizujesz swoje stoły? 70 to niezwykła kwota, chyba że celowo denormalizujesz wydajność (bardzo niewiele rzeczy ma 70 unikalnych atrybutów). Jeśli denormalizujesz ze względu na wydajność, zgodziłbym się z ChssPly76, że możesz użyć wszystkiego, na co pozwoli Ci baza danych.
Godeke
2
@KM. czy to ma być żart? Jestem nowy w MySQL i nie mogę go zrozumieć, czy masz na myśli, że JOIN jest dobrą rzeczą, czy czymś, czego należy unikać?
Elia Iliashenko
2
O ile łączenia są podstawową częścią SQL, dołączanie w celu dołączenia prawdopodobnie obniży wydajność i łatwość utrzymania dowolnej aplikacji.
jeteon

Odpowiedzi:

142

Jest uważany za zbyt wiele, gdy przekracza maksymalny limit obsługiwany przez bazę danych .

Fakt, że każde zapytanie nie musi zwracać każdej kolumny, jest całkowicie normalny; dlatego instrukcja SELECT umożliwia jawne nazwanie potrzebnych kolumn.

Zgodnie z ogólną zasadą struktura tabeli powinna odzwierciedlać model domeny; jeśli naprawdę masz 70 (100, co masz) atrybutów należących do tej samej encji, nie ma powodu, aby rozdzielać je na wiele tabel.

ChssPly76
źródło
29
@KM - dlatego powiedziałem „atrybuty należące do tej samej jednostki w modelu domeny”. Duża liczba kolumn w tabeli NIE powoduje jej zdenormalizowania; liczy się to, co przedstawiają wspomniane kolumny. Poza tym, chociaż normalizacja jest zdecydowanie dobrą rzeczą, NIE jest ona rozwiązaniem wszystkich problemów życiowych. Podstępne pytanie - czy uważasz, że liczba głosów obok pytania / odpowiedzi SO jest obliczana jak za select count(*) from voteskażdym razem, czy myślisz, że być może jest zdenormalizowana? Czy to sprawia, że ​​baza danych SO jest zła, a Jeff Atwood szalony?
ChssPly76
@ ChssPly76, to relacyjna baza danych, a nie model obiektowy. istnieją tabele, wiersze i kolumny, pracuj w ramach tego ograniczenia, jeśli chcesz uzyskać maksymalną wydajność, naśladuj obiekty dla wygody ze względu na wydajność. Czy zatem każda informacja o osobie powinna być przechowywana w tym samym wierszu? nie, podziel je i pogrupuj w różne tabele (na przykładzie mojego poprzedniego komentarza): „Osoba”, „Działania” „HealthRecords”. Przechowywanie SUMY ze względu na wydajność jest zupełnie innym problemem niż przechowywanie wszystkich danych w 70 kolumnach, aby uniknąć łączenia.
KM.
20
Czy „numberOfTeethPulled” powinien być częścią rekordu Person? Nie, prawdopodobnie nie powinno być w ogóle przechowywane - otrzymasz te informacje z „ToothExtractionRecord”, jeśli Twój model domeny wymaga takiego poziomu szczegółowości. Ale to TWÓJ (i ośmielę się powiedzieć, raczej wymyślny) przykład - nie ma to nic wspólnego z moim punktem widzenia: duża liczba kolumn w tabeli NIE oznacza, że ​​tabela jest zdenormalizowana. Pomyśl o umowach dotyczących nieruchomości / zamówieniach / innych dokumentach finansowych, żeby wymienić tylko kilka przykładów. Czy można je dalej podzielić na wiele tabel? Tak. Jakiś powód, żeby to zrobić? Nie całkiem.
ChssPly76
1
+1, to było zabawne. Jeśli tworzysz kolejną tabelę i będzie to po prostu relacja 1: 1, prawdopodobnie po prostu umieść ją w głównej tabeli. Nie pozwoli to zaoszczędzić miejsca, nie będzie działać o wiele lepiej, jeśli nie zażądasz danych, a nie będzie ich w ogóle w tabeli. Jedynym uzasadnionym powodem, który przychodzi mi teraz na myśl, jest to, że są tam poufne informacje, takie jak
numer PESEL
1
Jeśli mam jedną tabelę z 15 kolumnami, a drugą 300 kolumnami, klucz podstawowy obu tabel jest taki sam. Wybierz jedną kolumnę z dwóch tabel, czy wydajność będzie się znacznie różnić?
oferta nie może odmówić
28

Istnieją pewne korzyści z podzielenia tabeli na kilka z mniejszą liczbą kolumn, co jest również nazywane partycjonowaniem pionowym . Tu jest kilka:

  1. Jeśli masz tabele z wieloma wierszami, modyfikowanie indeksów może zająć bardzo dużo czasu, ponieważ MySQL musi odbudować wszystkie indeksy w tabeli. Podział indeksów na kilka tabel może to przyspieszyć.

  2. W zależności od zapytań i typów kolumn MySQL może zapisywać tymczasowe tabele (używane w bardziej złożonych zapytaniach wybierających) na dysk. To jest złe, ponieważ dysk I / O może być wielką szyjką butelki. Dzieje się tak, jeśli zapytanie zawiera dane binarne (tekst lub obiekt blob).

  3. Szersza tabela może spowodować wolniejszą wydajność zapytań.

Nie optymalizuj przedwcześnie, ale w niektórych przypadkach możesz uzyskać ulepszenia dzięki węższym tabelom.

jonstjohn
źródło
5
Dlaczego MySQL musi odbudować wszystkie indeksy w tabeli, jeśli tylko jeden jest modyfikowany?
Petr Peller
Zastanawiałem się nad tym samym. Dlaczego MySQL odbudowuje wszystkie indeksy w tabeli? Czy powyższe stwierdzenie jest prawidłowe?
maj
13

Jest ich za dużo, gdy narusza zasady normalizacji. Uzyskanie tak wielu kolumn jest dość trudne, jeśli normalizujesz bazę danych. Zaprojektuj bazę danych, aby modelować problem, a nie wokół sztucznych reguł lub pomysłów dotyczących optymalizacji pod kątem konkretnej platformy bazy danych.

Zastosuj następujące reguły do ​​szerokiego stołu, a prawdopodobnie będziesz mieć znacznie mniej kolumn w jednej tabeli.

  1. Brak powtarzających się elementów lub grup elementów
  2. Brak częściowych zależności od konkatenowanego klucza
  3. Brak zależności od atrybutów niebędących kluczami

Oto link, który pomoże Ci w tym.

JohnFx
źródło
17
It is pretty hard to get that many columns if you are normalizing your database.Nie tak trudne, jak się wydaje.
Petr Peller
5
Zdecydowanie nie jest to takie trudne. Wydaje się, że ludzie nie rozumieją normalnych form występujących wokół tych części. Możesz mieć 10000 kolumn i STILL być znormalizowane (nawet do najwyższej normalnej postaci).
Hejazzman
2
@foljs I właśnie w tym miejscu pojawia się przyjęta praktyka denormalizacji. Jeśli jesteś na skrzyżowaniu i samochód ma wjechać w ciebie, byłoby głupio czekać, aż światło zmieni się na zielone. Musisz zejść z drogi. Podczas gdy przejście przez czerwone światło może technicznie nie być legalne, robisz to, co oczywiście powinieneś zrobić, biorąc pod uwagę sytuację = denormalizacja
user3308043
3
Straciłeś mnie, kiedy zacząłeś mówić o samochodach. Nie mam pojęcia, jakie to ma znaczenie.
JohnFx
2
Jednak jak w tym scenariuszu wykonywać złożone zapytania z pojedynczą tabelą danych, nie możesz, musisz w dużym stopniu polegać na języku programowania i różnorodności innych rzeczy, aby to zadziałało! Więc równie dobrze mógłbym wrócić do tabeli zawierającej 170 kolumn, ponieważ posiadanie zapytań „JOIN” i bardzo skomplikowanego programowania, które wymaga tworzenia oddzielnych tabel, wydaje mi się stratą czasu. Chyba jestem wielkim fanem zasady KISS.
Vlad Vladimir Hercules
0

Nie stanowi to problemu, chyba że wszystkie atrybuty należą do tej samej jednostki i nie są od siebie zależne. Aby ułatwić życie, możesz mieć jedną kolumnę tekstową z przechowywaną w niej tablicą JSON. Oczywiście, jeśli nie masz problemu z uzyskaniem wszystkich atrybutów za każdym razem. Chociaż całkowicie zniweczyłoby to cel przechowywania go w RDBMS i znacznie skomplikowałoby każdą transakcję w bazie danych. Dlatego nie jest to zalecane podejście do stosowania w całej bazie danych.

Zeeshan Ch
źródło
0

Zbyt wiele kolumn w tej samej tabeli może również powodować ogromne problemy w replikacji. Powinieneś wiedzieć, że zmiany, które zaszły w master, będą replikowane na slave ... na przykład, jeśli zaktualizujesz jedno pole w tabeli, cały wiersz będzie w

Dzisiaj
źródło