[MYSQL] Zaplanowanie bazy danych. Opcje

[Patman]

Witam. Prosiłbym o poradę dotyczącą nie skryptu, lecz zaplanowania bazy danych. Często na stronach internetowych pod zdjęciami, filmami, artykułami itd. można dodawać komentarze. Dla przykładu przyjmijmy, że chcę utworzyć galerię zdjęć i każde zdjęcie będzie można komentować.
Pytanie jest następujące: czy każde zdjęcie powinno mieć własną tabelę w mysql z komentarzami, czy komentarze z wszystkich zdjęć galerii mają znajdować się w jednej tabeli z informacją o id zdjęcia do którego później mają zostać przypisane? Sensowniejsza wydaje się być druga metoda, ale powiedzmy, że będzie to strona z grafiką i zdjęć do komentowania będzie kilka tysięcy i więcej...

[Fifi209]

Masz tabelki z komentarzami do zdjęć,filmów,artykułów razem 3 tabelki.

W każdej z nich masz pola:

id, user_id, content

I po problemie. Id ustawiasz jako auto_increment i primary key, user_id jako index + robisz powiązanie z tabelą userów (wymaga silnika innoDB)

[skowron-line]

Masz tabelki z komentarzami do zdjęć,filmów,artykułów razem 3 tabelki.

W każdej z nich masz pola:

id, user_id, content

I po problemie. Id ustawiasz jako auto_increment i primary key, user_id jako index + robisz powiązanie z tabelą userów (wymaga silnika innoDB)

Ja bym dal jedna tabele do komentowania wszystkiego
dodal bym tylko pole.

id_kat ( enum ( 0-film, 1-foto, 2-artykul, ... )

[Fifi209]

Ja bym dal jedna tabele do komentowania wszystkiego
dodal bym tylko pole.

id_kat ( enum ( 0-film, 1-foto, 2-artykul, ... )

Moje rozwiązanie przy kilu tysiącach zapewne będzie bardziej wydajne.
Dlatego użyłbym swojego. ;d

[Patman]

Jest możliwość przesyłania sobie wiadomości prywatnych między użytkownikami. Czy mogą wiadomości wszystkich użytkowników zostać dopisane do jednej tabeli? Tabela posiada 5 pól (id wiadomości, id nadawcy, id odbiorcy, treść, czas przesłania). Czy można to rozwiązać w taki sposób? Wiadomości będzie bardzo dużo.

[TrevorGryffits]

W obecnym kształcie raczej nie - chyba, że zadowoliłoby cię, że userzy, nie wiedzą komu (od kogo) wysłali (otrzymali) wiadomość, gdy druga strona skasowałaby wiadomość. W tym kształcie możnaby usuwać id z odpowiedniego usera (nadawcy lub adresata).

A tak normalnie to chyba dodać dwa pola adresat_usuniete i nadawca_usuniete. I podczas usuwania z jednej ze stron to sprawdzać, czy druga strona też już chciała usunąć. Jeśli nie - to tylko ustawiamy odpowiednie dodane pole na true, jeśli tak, to usuwamy cały rekord.

[Crozin]

Co do komentarzy: jeżeli masz absolutną pewność, że dla każdego typu (komentarze do np.: obrazów, filmów, piosenek) będą miały dokładnie taką samą strukturę i nigdy nie dojdzie do sytuacji, gdzie jeden typ różni się czymś od pozostałych to możesz tak jak radzi skowron-line dodać kolumnę identyfikującą typ.

Ale mimo wszystko odradzam taki sposób i radziłbym zrobić osobne tabele o takiej samej strukturze dla każdego z typów. Pewna niewielka część aplikacji się niepotrzebnie powtarza, ale za to zyskujemy dosyć dużo na jej elastyczności.

Co do wiadomości: jak najbardziej tak... jest to dobre rozwiązanie. A jeżeli chcesz do tego dodać możliwość usuwania wiadomości ze swojej skrzynki wystarczy dodać jedno pole typu enum, określająca kto usunął - jeżeli w ogóle.