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?

A dlaczego obawiasz się liczby rekordów?

Tak z marszu, to pomyślałbym nad tym, żeby stworzyć tabelę "oceny - słownik" i w niej trzymać wpisy dotyczące dostępnych ocen.

I teraz tak:
Dodając uczniowi ocenę, zapisujesz w tabeli łączącej: IDwpisu, IDrocznika, IDprzedmiotu, IDSzkoly, IDucznia, IDoceny i datę wpisu.
W tym momencie, największa tabela zawiera praktycznie same inty - przez co jest dość szybka do obróbki.

Równocześnie (najlepiej procedurami SQLowymi - np. pl/pgSQL ) z dodaniem wpisu obliczasz średnią ocen dla ucznia, przedmiotu, szkoły, danego rocznika i czego tam jeszcze chcesz - baza to zrobi szybciej niż Ty ładując te dane do php, analizując i zapisując z powrotem.

Dlaczego polecam zapisywać te wszystkie ID? Bo uczniowie czasami zmieniają szkoły - i w tym momencie nie dośc, zę będziesz mógł sprawdzić, jaką średnią ma uczeń w danej klasie, to jeszcze w danej szkole itp - możliwości analizy są nieograniczone.

Bazy danych są po to, aby w nich przechowywać dane. Sprytnie zbudowana nadmiarowość i użycie procedur to automatycznego liczenia podstawowych przynajmniej danych może sprawić, że do uzyskania dowolnego wyniku wystarczy jedno, dwa zapytania - a przez to sama aplikacja też będzie szybka.

Do tabeli łączącej musiałbym zapisać jeszcze idKolumny (dziennik podzielony jest na kolumny z różnymi wagami), idPozycji (w dzienniku są kratki, nie zawsze nauczyciele wpisują oceny od lewej strony) oraz ewentualnie wagę (chodź można ją pobrać z tabeli kolumny)

Licząc średnią dla danego rocznika, i tak muszę najpierw obliczyć średnią dla każdego ucznia osobno, nie wystarczy zwykłe AVG po idRocznik-u.

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.

EDIT:

Ok, przygotuje i przedstawię schemat graficzny bazy.

http://www.postgresql.org/about/


75 milionów rekordów to naprawdę nie jest dużo - przypominam, ze trzymasz w tej dużej tabeli same INT.

Jeszcze raz powtarzam - tu nie ilość danych jest problemem, tylko umiejętne zautomatyzowanie obliczeń dla dodatkowych danych, które wynikają z tych wprowadzonych przez użytkowników. A tu już wychodzimy z tematu Projektowanie do tematu Optymalizacja.

Update:
Proponuje, żebyś w formie graficznej zaczął rozrysowywać tę bazę - wtedy będzie wiadomo gdzie które dane leżą oraz gdzie jaka kolumnę dodać - dla chociażby średnich. Wtedy będzie można zaplanować triggery i funkcje. Dodatkowo wtedy temat może tez przyciągnąć więcej osób będących większymi wyjadaczami w temacie BD niż ja - a wielu tutaj takich jest.

Witam

Przedstawiam strukturę bazy danych


Rok szkolny można podzielić na semestry lub trymestry dlatego w tabelach klasy_przedmioty oraz przedmioty_uczniowie występują kolumny semestr_1_srednia, semestr_2_srednia, semestr_3_srednia. W semestrach trzecia kolumna nie będzie wykorzystywana

Założenia
Do klasy można przypisać dowolną ilość przedmiotów. Każdy przedmiot może mieć dowolną ilość kolumn. W każdej kolumnie występuje 10 ocen oraz waga.

Baza: MySql

Witam jestem nowy więc proszę o wyrozumiałość. Schemat bazy danych tego dziennika wydaje się być naprawdę dobry ale nie rozumiem go w pełni może ktoś mnie troche oświecić co robi tabela ocena_kolumny? co jest w niej przechowywane? i czy w tej bazie danych pojedyncze oceny też mają wagi?

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


Ale mniejsza z ocenami, prawdziwa zabawa to się zaczyna przy nieobecnościach

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.

i IDKlasy, żeby policzyć która ma najlepszą średnią i będzie stała ze sztandarem
Bo jak rozumiem IDrocznika opisuje czy to jest 2 czy 3 klasa.

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

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

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.