ilość kolumn w tabeli, wpływ na wydajność Opcje

[fiszol]

Dzieńdobry. Zastanawiając się przed chwilą nad wyglądem jednej z tabel w mojej bazie danych doszedłem do wniosku, ze będzie miała ~52 kolumny (wszystkie int(12)). Narodziło się pytanie - czy to ma jakiś wpływ na pracę MySQL? Dla mnie, te 52 kolumny to dużo, nigdy nie używałem tylu. Może lepiej pomyśleć jak rozbić tabelkę na połowę a może nawet trzy części i operować joinami później?

[Sephirus]

Jeśli to są same inty tak jak piszesz to nie powinno być problemu - różnica w wydajności może wystąpić przy InnoDB jeśli masz dużo indeksów - bo im więcej indeksów tym dłużej trwa dodawanie rekordów.

Ja w jednej tabeli (w firmie) mam tabelkę która ma 90 pól różnych typów i śmiga normalnie - dodatkowo ma jakieś 4mln rekordów - więc samo w sobie aż tak dużego wpływu liczba pól nie ma - dopiero indeksów przy dodawaniu.

[alegorn]

hmmm.

sprawa nie jest prosta.
dla zwyczajnego zastosowania - owe 52 kolumny to ani malo, ani duzo. da rade.

pamietaj jedynie, by nie wybierac danych za pomoca select * from tylko potrzebne kolumny.


jesli potrzebujesz cos maksymalnie szybkiego - to trzeba wiecej zabawy poswiecic przy projektowaniu np kolumny o definiowanej i stałej szerokosci, tzn char zamiast varchar, stosowanie minimalnych wielkosci dla rozmiarow pol np smallint zamiast int, a juz w zadnym razie bigint.. odpowiednio zakladane indexy.. itp.
no, ale to juz osobna zabawa, i bardzo zalezy od tego, gdzie potrzebujesz wydajnosci. czy przy zapisie - czy tez przy odczycie (kwestia odpowiedniego zastosowania indexow)

tak naprawde, kazdy projekt jest inny. sa ogolne zasady, ktorymi trzeba sie kierowac przy projektowaniu (normalizacja itp) ale to tak naprawde wszystko zalezy od projektu
zdazalo mi sie swiadomie lamac zasady normalizacji danych, spowodowac ze czas insertu dla danej tabeli bylby nie do przyjecia na dyzych serwisach - ale udalo mi sie dzieki temu uzyskac zadawalajace wyniki dla zapytan.. srednia odpowiedz api to ok 0.02 sec (przy kilku milionowych tabelach + filtrowanie danych) insert/update tutaj byl bez znaczenia.

j.

[nospor]

No i zacznijmy od tego, czy naprawdę potrzebujesz aż 52 pól tabeli? To tylko sugestia, ale może źle zaprojektowałeś bazę? Napisz co to ma być, a może się okazać, że da się to zrobić zupełnie inaczej.

[fiszol]

Wydaje mi się. że potrzebuję aż tylu kolumnl. Każde z pół reprezentuje jakąś jednostkę(a raczej jej ilość) (mówimy o grze) .14 jednostek ofensywnych, 8 defensywnych, muszę zapisać stan przed walką i po walce (zamiast po walce mogę zapisać różnice, to zawsze będą mniejsze wartości) = 44 koliumy. 4 kolumny na ewentulanie przejęte surowce, id wpisu, id właściciela, id miejsca zdarzenia., data. Selecty będą odbywać się wdłg id & owner_id, lub id miejsca zdarzenia, czasami też z jakichś tam przedziałów czasowych. Wszystkie pola reprezentujące jednostki dostały default 0. W tej chwili około 100 użytkowników, rekordzista ma około 200 rekordów (zajeło mu to jakiś rok). Obecnie całość działa na dwóch tabelkach, osbno dla stanu jednostek przed walką i po. Nie zapisuję miejsca zdarzenia ani ilości surowców a to musi się zmienić. Pomyślałem. że skoro zmieniam to, może rozsądniej będzie upakować wszystko w jedną tabelę.