Ocenianie - optymalna baza danych


(jakubcjusz) #1

Witam

Piszę sobie właśnie skrypt do oceniania. I teraz pytanie, jak stworzyć optymalną bazę danych. Najprościej wyglądałoby to tak: id, id_obiektu, id_oceniajacego, ocena; Takie coś zapewni mi dostęp do najważniejszych informacji, jak kto co oceniał oraz jak oceniał. Niestety rozmiar takiego cuda będzie rosnąć wykładniczo. Ma ktoś może jakiś lepszy pomysł?


(Marcin Miga) #2

A co tu można zmienić? Jedyne co, to wywalić ID. I tak jest niepotrzebne, bo klucz zakładasz na parę (obiekt, user).

pozdrawiaMM


(jakubcjusz) #3

Pewnie masz racje. Ale chciałem jeszcze usłyszeć odpowiedź kogoś "z zewnątrz", żeby się upewnić, czy nic nie przeoczyłem rysując różne układy tabelek :slight_smile: No ale jeśli ktoś dozna cudownego oświecenia, to zapraszam. :smiley:

Dzięki za odpowiedź.


([alex]) #4

W niektórych przypadkach warto tabele Ocena podzielić na tyle tabel ile może być rożnych ocen. Wtedy do jednej z nich trafia rekord (id_obiektu,id_oceniajacego), ale przemyśl to kilka razy zanim zastosujesz.


(Pkolaczk) #5

Chętnie poznam takie przypadki. IMHO zupełnie bez sensu.


([alex]) #6

Ano pisałem na zamówienie oprogramowanie dla firmy.

Oceny było tylko trzy: "Najwyższa jakość", "Norma", "Wadliwy".

Wadliwe - kierowane na próbę naprawy - jeżeli udawało się naprawić to się przenosiło do tablicy "Norma", jak nie udawało się to na złomowanie.

Najwyższa jakość - pakowana osobna na jakieś specjalne zamówienia.

Tylko w jednym miejscu musiałem dawać trzy zapytania po kolei aby policzyć procent Wadliwych oraz procent Najlepszych.


(jakubcjusz) #7

Jedyną fajną sztuczkę jaką znam jest tableka: id_obiektu, ocena, ile_razy_wystawiona, (klucz: id_obiektu, ocena). Powoduje, że rozmiar tabelki ma tylko ilosc_mozliwuch_ocen*ilesc obiektow. Ale taka tabelka nie trzyma oceniajacego i jego oceny. Myślę, ze pomysł alexa mógłby się sprawdzić w małej bazie, ale w dużej to już będzie nie do opanowania.