[ivanhoe]

Sto se perfomansi tiche, mislim da ne posmatras to dobro...podela clanaka na strane nece bitno uticati na perfomanse, jer ce ljudi da citaju text u medjuvremenu, a sad da li ce na kraju procitanog texta da kliknu
na sledecu stranu ili na neki drugi text tvojoj bazi je svejedno, nece ti to stvoriti neki dodatni posao. Varijanta sa cuvanjem integralne verzije clanka je u tom slucaju losija po pitanju perfomansi jer ti svaki put iz baze moras da dovuces ceo clanak (sto je da kazemo 5,6 puta vise podataka), plus da ga parsiras da bi nasao stranu koja ti treba. Odvojene strane ce krace drzati zauzetu bazu i manje ce biti CPU intezivne.

Ako te perfomanse baze brinu (a ne mrzi te da programiras malo vise) mozes da cuvas gzipovane podatke u bazi, pa da ih otpakujes on the fly nakon dohvatanja iz baze. Iako deluje kao dodatna komplikacija, to u stvari povecava perfomanse jer baza mora da radi sa svega oko 10% realne kolicine podataka, a gzip je veoma brz, tako da se ukupno dobije na perfomansama.

Tako da sam ja za prvo resenje gledano iz ugla perfomansi, jedino sto je tu dodatni posao je resenje za editovanje texta. To je najlakse resiti tako sto ces sastaviti komplet text, dati ga na editovanje adminu(ili kome vec), i onda ga ponovo uvesti u bazu stranu po stranu. To omogucava da naknadno preraspodelis text po strana ako zatreba. Najzgodnije je da kad se kuca text pomocu neke oznake (taga) markiras page-break, i onda kad se text ubacuje u bazu, on se podeli po tim oznakama.

Ruku na srce, 600K strana mesecno i nije tako puno, tako da mozes sasvim lepo da prodjes i cuvajuci komplet textove sa mnogo manje programiranja...