Witam,

mam 2 tabele w bazie:

artykul: id_art | tytul | tresc
news: id_news | tytul | tresc

I teraz do artykulow jak i do newsow mozna dodawac komenatrze i moje pytanie brzmi: czy nalezy zrobic jedna tabele komentarze np.
komentarze: id_komentarz | id_art | id_news | tresc | dodano, czy moze dwie : koment_news i koment_art. Tylko jak w tej drugiej opcji sforumułować zapytanie, gdy chcę wyswietlic np. 3 ostatnie komentarze ?

Czekam na sugestie

Robisz tak

tabele z kolumanim

komentarz_id | komentarz_typ | tresc_komentarza | data_dodania | id_tresci


I teraz tak
ID to wiadome
kometarz_typ to TYP komentarza gdzie podajesz np A - artykuly N - newsy itp
tresc to wiadome
data tez wiadome
id_tresci to ide np newsa lub arykuła do którego dodano kometarz

POtem tylko np dla arykułów pobierasz komentarze dają WHERE komentarz_typ='A' a jak chcesz do kokretengo artykułu to tak
WHERE komentarz_typ='A' id_tresci='1'
gdzie 1 to id artykułu do jakiego dodano

dzięki wielki, o to mi chodziło

Bardzo zła praktyka moim zdanie. Nie powinno trzymać się danych ze sobą powiązanych w jednej tabeli. Co zrobisz jak za jakiś czas będziesz chciał dodać możliwość oceny artykułów a nie newsów? Dodasz kolumnę która w części przypadków będzie pusta. Jeśli zechcesz dodać komentarze w kolejnej części systemu, np. dla obrazka którego klucz główny będzie składał się z dwóch kolumn (id_galerii i nr_obrazka)? Dodasz kolumnę i zmodyfikujesz kod w nie wiadomo ilu miejscach narażając się na błędy wynikające ze zmian?

Nie ma limitu na ilość tabel, a upychanie w jedną to komplikowanie kodu, usztywnianie projektu i uniemożliwianie elastycznego rozwoju w przyszłości. Zachęcam do podzielenia danych na dwie tabele.

Przecież to jest dobre rozwiązanie a jak chcesz dodawać oceny to robisz drugą tabele na tej samej zasadzie i czyli glos_id | glos_typ | glos | data_dodania | id_gdzie_oddano_glos

Dobrze mam jeszcze jedno pytanie:

Chcę zrobić możliwość dodawania nowych artykułów dla użytkowników. Tylko przed tym, jak zostaną umieszczone na stronie, chcę je sprawdzić. I teraz pytanie, jak to rozwiązać na poziome bazy danych. Mam dwie opcje:
1. W tabeli artykul dodać kolumne "Sprawdzone", ktora bedzie miala dwie wartosci TAK, NIE, a na stronie będę wyświetlał tylko te sprawdzone artykuły
2. Utworzyć nową tabelę np. Artykuły_do_sprawdzenia gdzie będę przetrzymawał informacje tylko niesprawdzonych prac, a kiedy je zatwierdzę to dany wiersz tabeli "Artykuly_do_sprawdzenia" jest kopiowany do tabeli "artykuly" a nastepnei kasowany.

Czekam na sugestie

Jeśli chcesz oceniać tylko artykuły... bez newsow. W ten sposób i tak kończysz z dwiema tabelami i masą warunków w kodzie. Dlaczego od razu nie zrobić dwóch tabel, jednej na newsy a drugiej na artykuły? Takie wyjście jest dobre wtedy kiedy chcesz aby aplikacja faktycznie utożsamiała newsy z artykułami, np. wspólna lista - co i tak wydaje mi się słabym pomysłem. Po co kombinować jak dodanie tabeli upraszcza?


Nie ma sensu tego dzielić w tym wypadku. Dodaj kolumnę 'status' a w aplikacji podefiniuj różne statusy, np.:
0 - nie zatwierdzony
1 - zatwierdzony
2 - usunięty
3 - nie wiadomo jaki

Haha a jak będzie chciał rozbudować np. o komentarze do downloadu to co za każdym rzezem będzie nową tabele robił zamiast np. dać do tabeli komentarze np. komentarz_typ=’D’

Przecież na takiej zasadzie oceniasz wszystko co można w portalu w polu komentarz_typ dla Aryków dajesz A dla newsów N dla D i tak dalej można. PO co dla każdego robić osobną tabele.




Robisz dwie tabele w bazie danych jedną do nadesłanych artykułów druga do artykułów które będę się wyświetlać na stronie i tych zaakceptowanych już
Czyli tworzysz tabele np nadesłane z polami
Id | data_nadeslania | kto_nadeslal | tresc |

Opcjonalnie można zrobić kolumnę typ np. przypadku nadesłania artykuł będzie miała rekord A a w przypadku newsa N i po tem na tej podstawie rozróżniać co zostało nadesłane.

Potem w panelu admina wyświetlasz zawartość ten tabeli ( jak jest pusta to nic nie wyświetli czyli nikt nic nie nadesłał ) I jak chcesz odrzucić to po prostu kasuje rekord z tabeli nadesłane a jak chcesz zaakceptować to przenosisz rekord do tabeli artykuły

Drogi Panie Kefirek,

W tym momencie rozmawiamy o podtypach, a jak zapewne (nie)wiesz projektując bazę danych, podtyp można realizować na kilka różnych sposobów. W zależności od terminologii może to być realizacja generyczna (proponowana przez Ciebie), jawna (proponowana przeze mnie) lub hybrydowa. W generycznej jest jedna tabela zawierająca sumę kolumn wszystkich podtypów z kolumną określającą dany podtyp. W tym rozwiązaniu mamy wygodny dostęp do typu nadrzędnego, ale nieefektywny dostęp do podtypów(!). W przypadku realizacji jawnej, czyli dla każdego podtypu inna tabela. Realizacja ta stwarza problemy w dostępie do typu nadrzędnego i implementacji klucza typu nadrzędnego. Jest ona jednak zorientowana na optymalizowanie dostępu do podtypu (!). Hybrydowa to jedna tabela na wspólne kolumny (typu) i tabela dla każdego podtypu z kolumnami właściwymi tylko dla niego. Zarys wstępu do podstaw projektowania baz danych

Przypadek o którym rozmawiamy nie stwarza potrzeby utworzenia wspólnego klucza dla typu ani nawet jakichkolwiek operacji na nim. Rozważane są tylko podtypy i to na nie powinno być zorientowane rozwiązanie. Poza tym, implementacja generyczna jest zawsze trudniejsza i mniej elastyczna