Cześć, przebudowuję swojego CMSa i zastanawiam się jakie rozwiązanie będzie lepsze.
Mam tabele/sekcje news, videos, polls i w każdej z nich użytkownicy mogą dodawać komentarze. Do tej pory miałem news_comments, videos_comments, polls_comments. Nie wiem czy nie lepiej zrobić zbiorcze commnets i po prostu zrobić pole section gdzie wpisywałbym news, videos albo polls. Aktualnie mam łącznie ok. 100 000 komentarzy więc co lepsze myśląc perspektywicznie?

Ja mam zbiorcze z polem na typ/sekcje jak to wspomniales. Dzieki temu mam zawsze jeden kod na komentarze i przy zmianie zmieniam tylko ten jeden.
Przy roznych tabelach gdy chcesz dodac nowe komentarze do czegos innego to znowu musisz tworzyc nowa tabele i sie babrac.

Również polecam 1 tabelę zbiorczą. Jest to dość wygodne rozwiązanie

W mysql sensowne. W innych niekoniecznie. Np Postgres 10 ma pięknie partycjonowanie danych, do tego tabele dziedziczące. Dopóki nie masz tam rekordów idących w miliony to powinien sobie dać radę silnik mysql.

Dzięki za odpowiedzi. Będę robił zbiorczą - działam w MySQL.
Z kategoriami zrobić podobnie? Teraz mam news_category, videos_category.

tak

Pozwolę sobie podbić temat. W jaki sposób w przypadku takich zbiorczych tabel dbacie o integralność danych? Chodzi mi o rozwiązanie po stronie bazy danych. Pierwsza i chyba najsensowniejsza myśl jaka mi przychodzi do głowy to trigger ale może macie inne patenty. W przypadku Postgresa można przypiąć kilka trigerrow na to samo zdarzenie do jednej tabeli ale co w przypadku MySQL? Modyfikujecie ewentualny istniejący już trigger?

O jakiej integralności mówisz?

Pewnie chodzi o klucze obce, których tu nie zastosujesz.

Tak, chodzi mi o klucze obce, a konkretnie niedopuszczenie do sytuacji gdy istnieją komentarze do newsa, którego nie ma.

A jak ta tabela wygląda konkretnie? Bo newsy z komentarzami to zazwyczaj
newsy: id, cośtam
komentarze: id, id_newsa

Naprawdę trzeba się bardzo postarać żeby to zostawić luzem (bo nie widzę zastosowania żadnego do ustawiania null na on delete).

W mysql też da się ustawić kilka triggerów na 1 tabelę na to samo zdażenie np. BEFORE INSERT.
I tutaj to jest chyba jedyne sensowne rozwiązanie tylko że tutaj musisz ustawiać trigger nie na comments a na tabelę która będzie źródłem np. news.

Polecam używanie ORMa a tego typu problemy całkowicie znikają. Można nawet ustawić, by komentarze do artykułów to były inne obiekty niż do blogów a i tak wszystko zamapować na jedną tabelę - jak kto lubi. Rozstawianie po kątach sierot? orphanRemoval=true i problem znika.

@viking:
Mówimy tutaj o 1 tabeli z komentarzami do X obiektów (tabel) wiec klucza obcego nie postawisz.

@Pyton:
Fakt, od 5.7.2 można ustawić kilka triggerow - wow, w końcu ktoś odkrył taka możliwość! I to wg mnie rozwiązuje problem w sposób wygodny i elegancki.

@Pilsener:
Mi chodziło o zadbanie o to po stronie bazy danych, a nie aplikacji. Zdarza sie przecież ze jest potrzeba ingerencji w dane z poziomu bazy z pominięciem aplikacji wiec to sama baza powinna pilnować spójności danych.

Czyli np mialbys tabele artykułów i wiadomości a komentarze linkuja do pk obu tabel? I gdzieś jeszcze kolumna z typem tabeli (czy artykuły, czy wiadomości)?

Tutaj ciekawostka jak to jest rozwiązanie na poziomie ORM/Eloquent w Laravel:
https://laravel.com/docs/5.5/eloquent-relat...rphic-relations

Ale nie powiem - również lubię mimo wszystkie mieć porządnie zrobione klucze bo to jest zawsze druga linia zabezpieczeń aby nie mieć bałaganu w bazie. ORM o to zadba tylko wtedy gdy się nie pomylimy, zapytania wykonają się zawsze wszystkie i do końca itd. Poza tym klucze to też pewnie jakiś zastrzyk optymalizacji no i już taka trywialna korzyść, phpmyadmin linkuje fajnie ID do wiersza