Prikazivanje članaka na više strana

[Dzordz]

Eto dve moje teme za kratko vreme Sto znaci da radim nesto, a kad se radi uvek se ima i neka dilema. Radim u Javi mada to nije nesto bitno posto je ovo samo "filosofija".

Situacija:
Ubacujem neke clanke u bazu.
A posle ih prikazujem.

Problem:
Treba prikazati na vise strana jedan clanak.

Solucija 1:
Praviti vise unosa u bazi sa brojem strane, svaki put kad trazi stranu ide novi upit u bazu (nece biti pretrpano tako da ce to ici brzo). Moze se napraviti cini mi se bez nekih vecih problema.

Solucija 2:
Ucitam clanak koji je u celini u bazi sa nekim tagom koji odvaja strane. Izracunam broj strana, posaljem tekst strane koja je trazena ali i tekst ceo kao parametar, da bih ga onda opet vratio nazad u controler sa dodatnim parametrom trazene nove stranice.

Diskusija:
Solucija 1 je laksa za napraviti rekao bih ali pravi konstantne upite u bazu.
Solucija 2 stedi bazu ali "radi" vise.
Trebalo bi da radi na shared hostingu sa oko 600.000 prikazanih strana mesecno.

Misljenja iskusnijih kolega su dobrodosla

[Ilija Studen]

Ja sam uvek za čistiji dizajn aplikacije - prvo to. Ako stvarno naletiš na probleme sa performansama hakuj, mada ni to ne bi trebalo da bude problem jer uvek možeš da keširaš podatke.

Znači, moj glas za opciju br. 1.

[Alef]

Zavisi od logike aplikacije.
Ako su delovi članka logicki odvojene celine, tj. ne prestavljanju zajedno jednu celinu, onda je rešenje pod 1. Svaki deo treba da ima poseban unos u bazu.

Ali ako je članak jedna logička celina koja se samo prikazuje na više stranica, onda nipošto rešenje pod 1! Jedan članak jedan unos.

By the way, ne moraš odvajati stranice posebnim znakom... Jednostavno prelomi stranicu posle odgređenog broja linija, slova — tako ćeš uvek moći lako da stigneš do stranice koju želiš.

[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...

[zira]

I jedno i drugo rjesenje je OK. Ja licno bih za taj slucaj (pogotovo ako je to stvarno paginacija samo, a ne neke cjeline koje treba posebno obradjivati u nekom drugom smislu od prikazivanja) izabrao rjesenje br 2. I cini mi se lakse za odrzavanje.

@Alef: Uvijek je bolje rucno naznaciti gdje je kraj stranice, automatika u tom slucaju nije uvijek zgodna, jer se obicno radi o cjelinama teksta, pa je bolje da stranice ne budu striktno istih duzina, nego logicki podijeljene.

@ivanhoe: U slucaju zip-a, kako bi rijesio pretragu?

[jablan]

Ja se slažem sa Alefom. Ako su članci logičke celine, čuvati ih kao celine. Za deljenje na stranice može se koristiti ručno ubačen delimiter, ali treba razmisliti i o "inteligentnijem" rešenju koje bi automatski delilo tekst na zadati broj strana, ali vodeći računa da se stranice po mogućnosti cepaju neposredno pre, na primer, Hx taga.

Što se tiče optimizacije, ja ne volim da joj pribegavam pre nego što sam siguran da je zaista neophodna. Dakle, uvek polazim od što čistijeg i jednostavnijeg rešenja (u ovom slučaju čini mi se da je to varijanta sa integralnim člancima), a u optimizaciju krećem tek ako 1) imam potrebe i ako 2) sam siguran da će mi neki zahvat (npr. cepanje članaka) bitno poboljšati performanse.

[Ilija Studen]

Kod čuvanja stranica odvojenih separatorom mi se ne sviđa par stvari:

1. Deluje mi nekako prljavo - čim kod modelovanja baze treba da se koristi separator na nivou podataka kako bi se označila konstrukcija to mi ne smrdi na dobro.
2. Aplikacija mora da radi više - aplikacija je previše uključena u obradu podataka, ako može da se ide na to da kontroler samo servira podatke bez ikakve obrade na to bih išao (kao najjednosatavnije rešenje).
3. Čovek dođe i traži "firefly" npr. Ta reč se pojavljuje na trećoj stranici. Ti tehnički moraš da učitaš kompletan sadržaj, razbiješ ga, odradiš foreach or whatever dok ne nađeš stranicu gde se nalazi tražena reč i tek onda serviraš tu stranicu. Isto previše rada od strane aplikacije.

Ima tu još par stvarčica, ali ovo su najveće zamerke.

Kako god da okreneš, oba rešenja će raditi posao i OK su. S jedne strane imaš malo složeniji model (dodatna tabela + relacije) što neće predstavljati probleme ako imaš dobar ORM, s druge imaš konstantno veći load i aplikacije mora da zasuče rukave.

Iskreno, mislim da ovo neće previše uticati na performanse. Napravi da je najbolje dizajnirano, pa tek onda, ako stvarno počne da pravi probleme, lako ćeš proći i napraviti brže rešenje na osnovu konkretnih podataka koje budeš imao "na licu mesta" (broj hitova, broj upita, brzina izvršavanja etc). To je po meni bolje od dizajniranja aplikacije na osnovu pretpostavke koja lako može biti neispravna.

[ivanhoe]

Originalno napisao zira

@ivanhoe: U slucaju zip-a, kako bi rijesio pretragu?

paaaa, moze klasicno trazenje preko tabele pojmova, kao sto se radilo ranije pre nego sto je dodat full text search... imas tabelu svih keyworda i imas tabelu gde se cross-referenciraju keywordi i textovi u kojima se pojavljuju. Pretraga ti se onda svodi na jedan join nad te 2 tabele i tabele sa postovima. To je vrlo efikasno resenje..

[Dzordz]

Lepe informacije ekipa! Hvala!

Evo citajuci sve ovo razmisljam da verovatno necu imati vise od 1-2.000 strana tako da to nece predstavljati bilo kojoj bazi problem. (poen za soluciju 1)

Iako nije neka resurs-o-zderac aplikacija imam kosmare od prica ljudi o adminima koji gase aplikacije samo zato sto rabe malo vise JVM. (prebacivanje rada na bazu, jos jedan poen za resenje 1)
* desilo mi se to sa Joomla sajtom pre 4-5 dana , zato i pravim svoje resenje.


Sto se tice automatizovanja odvajanja strana to jednostavno nije opcija posto uvek imam razlicite kolicine slika po strani koje prikazuju ono sto se radi (tutoriali) a ne mogu ni da odvajam posle x slika zato sto nekad su mi potrebne i dve slike za redom da bih nesto prikazao.

[jablan]

Ok, očigledno su čoveku stranice logičke celine i više mu paše prvo rešenje, ali možda bi bilo korisno da nastavimo raspravu teoretski...

Originalno napisao Ilija Studen

1. Deluje mi nekako prljavo - čim kod modelovanja baze treba da se koristi separator na nivou podataka kako bi se označila konstrukcija to mi ne smrdi na dobro.

Ne znam zašto - evo npr svi tekst procesori (bogamu, da l' se još koristi ovaj izraz?) imaju "page break" - oznaku za novu stranicu. U pitanju je jedan dokument, a nova stranica se može posmatrati kao oznaka formatiranja: isto kao što blok koji je italik ne stavljaš u posebno polje u bazi, već ga ostaviš u tekstu uokvirenog EM tagom.

2. Aplikacija mora da radi više - aplikacija je previše uključena u obradu podataka, ako može da se ide na to da kontroler samo servira podatke bez ikakve obrade na to bih išao (kao najjednosatavnije rešenje).

Ovo jeste tačno, ali je operacija traženja fiksnog delimitera u tekstu od par KB vrlo brza operacija, nisam siguran da tu zaista štediš nešto značajno.

3. Čovek dođe i traži "firefly" npr. Ta reč se pojavljuje na trećoj stranici. Ti tehnički moraš da učitaš kompletan sadržaj, razbiješ ga, odradiš foreach or whatever dok ne nađeš stranicu gde se nalazi tražena reč i tek onda serviraš tu stranicu. Isto previše rada od strane aplikacije.

Obično se pri pretrazi vraća link na članak, a ne na stranicu u članku. Sa te strane mi je logičnije da se članak drži integralno... Ako ćemo da cepidlačimo, da bi od stranice dobio članak, ti moraš da uradiš dodatni JOIN.