Pomoc - Szukaj - Użytkownicy - Kalendarz
Pełna wersja: [MYSQL] Zaplanowanie bazy danych.
Forum PHP.pl > Forum > Przedszkole
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
Cytat(fifi209 @ 30.07.2009, 12:53:15 ) *
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
Cytat(skowron-line @ 30.07.2009, 13:58:31 ) *
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. winksmiley.jpg
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.
To jest wersja lo-fi głównej zawartości. Aby zobaczyć pełną wersję z większą zawartością, obrazkami i formatowaniem proszę kliknij tutaj.
Invision Power Board © 2001-2025 Invision Power Services, Inc.