Jak myślicie, czy pomysł z zapisem rozbudowanych stron html (treści strony(podstrony dokładniej) wraz z indywidualnymi znacznikami html/js dla danej strony (typu span, p itd)) w bazie danych jest dobrym pomysłem? Może lepiej zapisywać je w pliku tekstowym ?
Zależy mi na możliwości edycji tych danych z poziomu przeglądarki
Co powinno szybciej działać?

Z góry dzięki za pomoc.

Pliki bo to treść dość statyczna - edycja tylko, gdy Ty będziesz miał ochotę.
Z resztą prościej coś "zabrać" z pliku niż z bazy. ;]

Baza danych, bo:
1. Pewnie i reszta danych jest w niej trzymana, a wygodniej jest mieć wszystko w jednym miejscu.
2. Łatwiej tym zarządzać.

W plikach też może oczywiście być. Przy takich "wymaganiach" każde rozwiązanie będzie równie dobre co złe.

hehe wymagania - ciężko nimi nazwać jedno zdanie chodzi mi o szybkość działania i łatwość użycia. Crozin masz racje, reszta jest w bazie Raczej zrobię to w bazie, tak jak myślałem na początku

A ja przerwę drakę i powiem, że i tu i tu
W bazie trzyma się całość a cache robi się w plikach. Najlepiej cachować gotową, wygenerowaną podstronę wtedy gdy ktoś ją odwiedzi a cachować stare pliki cache za pomocą crontaba (lecisz co 24h i sprawdzasz których data użycia jest starsza niż np. 10 dni), oraz gdy następuje edycji/kasowanie podstrony.

Wystarczy nowe cache robić tylko podczas dodania nowych danych/edycji/kasowania, nie trzeba akurat co 10 dni (wiem wiem, przykład).

Ja stosuję u siebie często rozwiązanie następujące. W bazie mamy dwa pola, np. content oraz content_html. Przy zapisywaniu dokumentu przechodzi ona przez jakiś parserek, który produkuje ze znaczników kod HTML. Oryginalną treść, która jest potrzebna wyłącznie do celów edycyjnych kompresuję i zapisuję w content, zaś treść w formacie HTML ląduje w content_html. Podczas wyświetlania pobieram jedynie content_html. Jeśli jest potrzeba, nakładam na to dodatkowo jakiś cache, żeby nie trzeba było łączyć się z bazą w celu pobrania treści.

Zyx wydaje mi się, że jednak tracisz miejsce - niby mały problem, bo dziś koszt jednego gigabajta to drobiazg ale... ;p

@fifi209: Wiesz, że to się nazywa... cache?

Z tego co widzę każdy ma wypracowany sposób jak pracuje mu się najlepiej i wg. niego jest najwydajniej Z cache dobry pomysł, na pewno zrobię tak jak mówicie

Miałem na myśli zapisywanie w bazie dwóch wersji + cache, wystarczy jedna i cache. ;p

Cache jest opcjonalny, w dodatku może być robiony w pamięci RAM. Jeśli dokładnie wiemy, kiedy przetworzona zawartość może się zmienić, nie musimy stosować mechanizmów cache z czasem życia, bo po co? Rozwiązanie ma tę zaletę, że dzięki takiemu podziałowi nie trzeba korzystać z cache, co ma duże znaczenie w sytuacji, gdy skorzystać z niego nie można (np. gdy zwracane dane zależą od konkretnego użytkownika, ustawień personalizacyjnych i uwzględnienie każdego możliwego przypadku mogłoby doprowadzić do zapchania serwera).

@fifi: O jakich dwóch wersjach i cache Ty piszesz? Przecież ta wersja content_html jest jest właśnie cache. Przecież cache może być trzymany w bazie danych.

Crozin jaki sens ma trzymacie cache w bazie? Chyba chodzi o ograniczenie zapytań do bazy.

Taki sens, że nie robisz złączeń, nie przetwarzasz danych, nie generujesz html. Tylko pobierasz i ładujesz na stronę.

Źle mnie zrozumiałeś
Chodziło mi o to, aby coś co piszemy było skalarne - z crona wywalasz pliki cache nieużywane przez dłuższy okres. W małym serwisie gdy artów jest np. 10 nie ma problemy, 100 już gorzek, le jak w serwisie robi się np. 10 artów dziennie (czy też newsów) to zakładając, że 1 art = 1 plik cache to przez rok masz ponad 3600 plików jednego typu
A po co trzymać cache czegoś czego nikt dawno nie odwiedza po za google za ruski rok?