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

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:

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

Brak powtarzających się elementów lub grup elementów
Brak częściowych zależności od konkatenowanego klucza
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