Witam

Dostalem do robienia projekt który bedzie dosc szybko się rozrastal. Załozenia są takie ze sie nagromadzi ok 18 milionów rekordów w ciągu roku. Struktura bazy jest dosyc prosta. Jedna tabela Userzy i UserzyWpisy z ok 30 kolumnami (integer, date, decimal). Bedze to budować w oparciu o Zenda i Doctrine. Dane bedą potem uzywane do obliczania naleznej kwoty do zaplaty, na podstawie wpisow z calego roku, w trybie tygodniowym czyli dla danego tygodnia 7 wpisów dla jednego usera.

Pytanie jest takie, co lepsze będzie:
Czy 7 osobnych rekordów w tabeli UserzyWpisy, czy 1 dlugi rekord dla jednego usera w UserzyWpisy z kolumnami na kazdy dzien czyli ok 30x7 = 210 kolumn.

wg mnie pierwsze rozwiazanie jest ok, bo mam wiekszą kontrolę nad zmianami, jak np dojdzie jedno pole nowe.
Jak to sie ma do wydajnosci mysqla? Joinow w jedynm zapytaniu bedzie sztuk 1. Złaczenie User i UserWpisy, a jedynymi operacjami będą rozne kalukacje (dodaj, odejmij) na danych w bazie.

Bedą indeksy, będą odpowiednio dobrane typy kolumn, cache w doktrynie. Na co jeszcze zwórcic uwage? nie chcialbym się w ciemny las zapędzic. Proszę o opinie osoby ktore robily takie projekty.

alex

Lepsze to pierwsze, ponieważ wtedy nie będziesz pobierał danych, których dość często nie potrzebujesz. Poza tym nie opisałeś co to za pola, jakie pełnią funkcje, jak często dane z tych pól używasz

210 kolumn? A chcesz do tego żyletkę, żeby od razu się pociąć?

Na dobrym serwerze, przy dobrych indeksach będzie działać. Jeśli struktura danych na to pozwala, możesz pobawić się w partycjonowanie. Najbardziej bałbym się, że Doctrine wymyśli jakieś nieszczególnie optymalne zapytania.

te kolumny bedą przechowywac dane liczbowe (unsigned 0 .. 10 000 000), oraz walutowe (np 100.25). nie bede robic zadnego szukania w tekstach, tylko pobieranie wszystkich rekrodow za dany okres i przeliczanie i potem wydruk na kwit. tak ze cudow tam nie bedzie.

Nie cuduj. Tabele 'wąskie i długie' są lepsze niż 'szerokie a krótkie'

A jeszcze żeby rozwiać wszystkie wątpliwości
http://dev.mysql.com/doc/refman/5.0/en/col...ount-limit.html

no i tak zrobie. bedzie 7 rekordow na jeden tydzien dla user_id. kolumn 30 ok wg typow co podalem. Poczytam jeszcze o tym partyucjonowani. dzieki za pomoc.

4 bajty INT, 8 bajtów DATE, załóżmy 6 bajtów na DECIMAL = 18 bajtów na trzy kolumny
70 * 18 = 1260B < 64kiB - mieści się co nie znaczy, że warto iść tą drogą.