Struktura bazy danych - internetowy dzienniczek ucznia, Schemat przechowywania ocen uczniów Opcje

[woj_tas]

Witam.

Zastanawiam się nad sposobem przechowywania ocen w internetowym dzienniczku ucznia. Przechowywanie każdej oceny w oddzielnym rekordzie przy założeniu, że z aplikacji korzystać będzie ok 1000 szkół, jest dość problematyczne. Myślałem o podziale ocen na kolumny (z różnymi wagami - potrzebne do średnich warzonych). W każdej "kolumnie" 10 ocen. Kolumna przypisana byłaby do danego przedmiotu (w danym przedmiocie max 4 może 5 kolumn co daje ok 40, 50 ocen z przedmiotu). Każdy rekord zawiera informację o przedmiocie, uczniu, wadze oraz 10 ocen. Z ilością rekordów schodzimy 10-krotnie

Co wy na to?

[modic]

Co do liczby rekordów. Zakładając 1000 szkół x 500 uczniów x 10 przedmiotów x 15 ocen daje nie małą sumę 75 000 000 rekordów.

nie zgodziłbym się z tym, uczeń ma średnio w ciągu roku ok 200 ocen łącznie ze wszystkich przedmiotów (przynajmniej tak wychodzi z mojego doświadczenia), ale może być też więcej. A jak oceny są przechowywane np. 3 lata to masz dodatkowy problem

1000 szkół x 500 uczniów x 200 ocen x 3 lata = 300 000 000

Z moich testów wynikało że tabela przechowująca oceny przy 5 mln rekordów miała (przy założonych indeksach), ok. 500mb
Bez indeksów wyszukiwanie ocen ucznia trwało 30-50s, z indeksami ok 0.03s, a jak wynik był cachowany to jeszcze krócej (IMG:style_emoticons/default/smile.gif)


Ale mniejsza z ocenami, prawdziwa zabawa to się zaczyna przy nieobecnościach (IMG:style_emoticons/default/smile.gif)

1000 szkół x 500 uczniów x 1800 godzin lekcyjnych w roku x 3 lata = 2 700 000 000

Jednak jak się pokombinuje to można by zmniejszyć ilość rekordów przy frekwencji o 80%

Ten post edytował modic 13.06.2011, 18:35:59

[scanner]

Ale mniejsza z ocenami, prawdziwa zabawa to się zaczyna przy nieobecnościach (IMG:style_emoticons/default/smile.gif)
1000 szkół x 500 uczniów x 1800 godzin lekcyjnych w roku x 3 lata = 2 700 000 000
Jednak jak się pokombinuje to można by zmniejszyć ilość rekordów przy frekwencji o 80%

I to wg. Ciebie jest dużo?
Primo: Przechowujesz nieobecności, a nie obecności. To zmniejsza ilość danych o 90%
Secundo: Jeden z naszych systemów ma po roku działania 6 922 096 rekordów w jednej tylko tabeli - i jakoś nikt z tego powodu nie załamuje rąk. Inny system, który jest dość intensywnie używany ma bazę wielkości 6 325 MB - z indeksami i całą resztą. I też nie ma problemów z działaniem.


Odpowiedni projekt i optymalizacja bazy i nie ma problemu.

[Sephirus]

Odpowiedni projekt i optymalizacja bazy i nie ma problemu.

Całkowicie się zgadzam - sam mam w firmie forum, którego baza przekracza 20GB i działa płynnie, pojedynczo bez żadnych replikacji itp. (a to przy naprawdę sporej liczbie dziennych odsłon)

Grunt to aby struktura była oparta na wielu tabelach i połączeniach między nimi i do tego indexy, indexy, indexy. Możesz pomyśleć też - jeżeli nie do końca wiesz jak to optymalnie zrobić - nad archiwizacją niektórych rzeczy - idea prosta - duplikujesz całą bazę i zapisując ją jako archiwum - powiedzmy zamykasz do archiwum dane po roku szkolnym czy określonym możliwym momencie. Na bieżąco korzystasz z podstawowej bazy a jeżeli ktoś chce zasięgnąć "historii" to zabiera się za archwium - można to ładnie oskryptować by osoba korzystająca z tego nawet o tym nie wiedziała (IMG:style_emoticons/default/wink.gif)

Ważne jest też obciążenie samej bazy - bo jeżeli mało użytkowników będzie z tego korzystać i rzadko to nie ma problemu ale jeżeli dużo i prawie non-stop to nie ma co ukrywać, że i mocny sprzęt się przyda ogólnie (IMG:style_emoticons/default/wink.gif)

EDIT: Widzę, że jako bazy chcesz użyć MySQL - ok a jaki mechanizm składowania? MyISAM będzie prawdopodobnie gorzej działał przy dużym obciążeniu więc dałbym to conajmniej InnoDB - co jest możliwe.

Ten post edytował Sephirus 30.06.2011, 07:26:43