Jest 5 typów zawartości: artykuły, pliki, media, linki, newsy. Można dodać nowe typy. Każdy z nich ma osobną tabelę, np. arts, files. Każda pozycja jest przypisana do jednej z istniejących kategorii.

Na stronie głównej jest zawartość z wybranej kategorii. Domyślnie newsy. Takie rozwiązanie sprawdza się tylko w serwisach, gdzie często pisze się newsy, prowadzi bloga, o nowych rzeczach też pisze się newsy (np. wyszła nowa wersja, dodany nowy program, są nowe tapety). Czemu nie skorzystać ze sprawdzonych metod? Wzorem jest tablica na FB. Można wyświetlać na stronie głównej wszystkie lub wybrane elementy. Pozostają kwestie implementacji:

1. Wyświetlamy najnowsze pozycje wszystkich typów i może coś jeszcze
2. Trzeba sprawdzić, czy kategoria jest dostępna, czyli JOIN z tabelą `cats`
3. Trzeba ustalić jednolity wygląd każdego typu (streszczenie) dla strony głównej

Co najmniej 5 zapytań z JOIN połączonych UNION? To zarżnie serwer. Są 2 wyjścia:

1. Cache - odświeżać po dodaniu/edycji/usunięciu dowolnej pozycji lub kategorii
2. Stworzyć indeks pozycji w 1 tabeli - więcej miejsca, ale odwołujemy się tylko do 1 tabeli

W pierwszym przypadku wystarczy dołączyć cache i jazda. Jeżeli jest dużo pozycji i chcemy je wyświetlać na kolejnych stronach (1,2,3,4 .. 150) lub po kliknięciu "Więcej" jak na FB, trzeba je skądś wczytać. Tworzyć cache dla wszystkich stron? To też nieopłacalne. Drugie rozwiązanie też wymaga kopiowania treści i danych, czyli baza będzie się rozrastać.

Macie ciekawy pomysł, co powinno być na głównej w dobrym systemie CMS i jak to zaimplementować?

O zawartości głównej decyduje opiekun tego cms Bez cache się nie objedzie i to jeszcze trzeba by było opakować w "cron", np przy dużym zainteresowaniu, tworzyć cache tylko na np tydzień i w cronie, starsze wersje kasować jakby zalegały.

Nie wiem jak to jest rozwiązane na FB, ale tu nawet nie ma co porównywać, zupełnie inne mechanizmy. Po prostu jak coś dodasz, to po 1. wcale nie musisz tego zobaczyć od razu jako wynik z bazy, wystarczy odświeżyć widok w JS. A dane wczytujesz tylko wtedy, gdy ktoś o nie zapyta, wtedy wrzucisz to do cache i tyle, a jak ktoś nie będzie tego szukał przez tydzień, wtedy w cronie to skasujesz.

I tak naprawdę nie ma znaczenia czy zapytań do bazy masz 2 czy 20 (w większości przypadków i tak tego nie zauważysz, jeśli chodzi o wydajność, chyba że masz mało optymalną strukturę). Ważne żeby były wykonywane tylko w razie potrzeby.

Ja używam następującego sposobu implementacji: strona jest tablicą elementów (typu style, meta) która łączy się z szablonem, natomiast content dołączam na dwa sposoby: używam paneli oraz modułów. Panele tym się różnią od modułów, że stanowią statyczny HTML i nie wymagają panelu administracyjnego, natomiast każdy moduł ma taki panel a treść tworzy w sposób dynamiczny.

Mamy np. moduł "losowa fotka". Moduł generuje jakiś HTML i style (albo inne rzeczy), które są dołączane do tablicy strony. W PA modułu ustawiamy szablon HTML, ilość fotek, sposób działania cache i inne tego typu rzeczy włącznie z nazwą zmiennej, którą moduł generuje. Każdy moduł jest na swój sposób autonomiczny.

System ma strukturę drzewa - do dowolnej gałęzi można podpiąć dowolną ilość modułów oraz paneli. Gdy zaznaczymy, że strona główna ma moduł "losowa fotka" na ON to moduł jest includowany i w szablonie podpiętym do tej gałęzi mamy do dyspozycji zmienną o konkretnej nazwie, którą możemy dowolnie wykorzystać.

Najczęściej to administracja ma decydować o tym, co się pokaże na stronie głównej (w sumie jedyne logiczne rozwiązanie, inaczej zaraz na głównej byłyby jakieś głupoty) i warto przewidzieć taką opcję. Tu się właśnie przydaje decentralizacja - działamy tylko na module "losowa fotka" i nic nas nie obchodzi ani szkielet systemu, ani sam moduł dodawania zdjęć. Łatwo też użyć modułu w innych systemach.