Założenia są mniej więcej takie:
- istnieją konta użytkowników;
- każde konto należy do jakiejś grupy (moderator, administrator, śmiertelnik itp.);
- użytkownik może dodawać swoje projekty do portfolio, newsy do bloga, zgłaszać pomysły na projekty;
- użytkownik może je oceniać, przy czym informacja o tym kto jaką ocenę wystawił nie jest przechowywana;
- użytkownik może je komentować;
- istnieją informacje o narzędziach (językach, bibliotekach) zastosowanych w projektach, typie narzędzi (backend, frontend, grafika), oraz użytkownikach którzy ich użyli (przy czym nad jednym projektem mogło pracować kilku użytkowników);
- pomysły zgłaszane są w rundach, po każdej rundzie głosowanie na pomysł się zamyka i można wyłonić najlepiej oceniony pomysł
- pomysły, projekty, newsy mogą być w prosty sposób zestawione na jednej stronie
- istnieje możliwość ukrycia danych o użytkownikach i obiektach które stworzyli, bez konieczności usuwania (pola hide).
Projektując tę bazę kierowałem się zasadami wykładanymi na uczelni, niemniej kwestia optymalizacji, ze względu na nie do końca ścisły kierunek studiów, była przez prowadzących pomijana. I mam tutaj na myśli optymalizację czasu dostępu do danych, bo jeśli chodzi o normalizację, starałem się jak mogłem;). Szczególne wątpliwości miałem w momencie przekształcenia relacji IS-A. Początkowo nie było tabeli "objects", przez co projekty i pomysły musiały mieć osobne tabele z ocenami i komentarzami. Uznałem, że jest to jednak niezbyt elastyczne (eleganckie?) i wprowadziłem tę tabelę jako nadrzędną klasę. Robiłem to z nadzieją, że ułatwi to dodawanie nowych funkcjonalności serwisu (dodawanie nowych obiektów) bez znacznej ingerencji w obecną bazę. Bardzo proszę, wytykajcie mi błędy, na uczelni już nikt tego nie zrobi, a ciągle czuję się ubogi w wiedzę
.Poza tym mam też kilka bardziej technicznych pytań. Bazę projektowałem w mysql-workbench. Zdziwiło mnie, że kiedy ustawiałem w projects, news i ideas klucz obcy do objects.id_objects, tworzyła się relacja 1-wielu. Po kliknięciu na relację prawym przyciskiem myszy, ustawiłem ją jako 1-1, jednak nie zauważyłem żadnej zmiany w strukturze bazy. Może mi to ktoś wytłumaczyć?
I kolejna sprawa, to relacje 0-wiele, przy coments i used_tools. Uznałem, że nawet po usunięciu użytkownika wypadałoby nie usuwać tych wpisów, tylko potraktować je jako stworzone przez przez anonimowego użytkownika (raczej hipotetyczne, raczej nie będę usuwał użytkownika, razem z jego id... ale
). No więc ustawiłem user_id jako pola, które mogą przyjmować NULL. Co jednak z kluczem tabeli users, które jest autoinkrementowane? Też powinienem dać tam możliwość wystąpienia NULL? Stworzyć użytkownika o id_users równym NULL? Czy też nie jest to konieczne i nie będzie żadnego konfliktu więzów?//edit
Prośba do moderatora, nie wiem, czy nie przesadziłem z umieszczaniem tego tematu w subforum MySQL (z rozpędu, gdyż w tym właśnie środowisku pracuję). Jeśli tak, przepraszam i proszę o przeniesienie do ogólnego działu.
Zauważyłem pewne niedociągnięcie w strukturze tej bazy, właśnie w przekształceniu relacji IS-A. Mianowicie, może się zdarzyć, że object będzie wszystkimi swoimi podtypami na raz. Tzn, klucz główny jest w tabeli objects, a tabele projects, notes i ideas są z nią w relacji jeden do jeden. Nie jest jednak powiedziane, że object_id w projects musi być inne niż object_id w notes. Teraz stoję przed dylematem. Z jednej strony, mogę przecież na poziomie aplikacji zadbać o to, aby w trakcie tworzenia obiektu wybierana była tylko jedna podklasa. Z drugiej strony, wydaje mi się, że powinienem dodać nową tabelę object_types, w której byłyby typy obiektów, i byłyby one kluczem w tabeli objects i w poszczególnych podklasach to zapewniłoby unikalność wpisów... jednak moim zdaniem dużym kosztem.
Czy powinienem dodać kolejny klucz kosztem szybkości wykonywanych operacji na tabeli, czy też zostawić to tak jak jest i uważać tworząc aplikację? A może jakieś inne, lepsze rozwiązanie?