PDA

Pogčedajte punu verziju : Prikazivanje članaka na više strana


Dzordz
24. 09. 2006., 17:54
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 :1064:

Ilija Studen
24. 09. 2006., 18:00
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
24. 09. 2006., 19:40
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
24. 09. 2006., 21:30
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
24. 09. 2006., 21:50
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
24. 09. 2006., 23:33
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
25. 09. 2006., 02:05
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
25. 09. 2006., 04:05
@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
25. 09. 2006., 06:59
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
25. 09. 2006., 10:30
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...
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.

bluesman
25. 09. 2006., 11:55
Kod prvog rešenja, gde je svaka strana poseban record, treba obratiti pažnju na pretraživanje jer može da se desi da za isti query izbaci recimo 5 rezultata, a svih 5 su isti tekst. Meni bi to smetalo, ali to ne mora da bude bug, može da bude i feature.

Zatim, šta se dešava kada treba da se zameni redosled? Kod prvog rešenja moraju da se tumbaju recordi odnosno da se menja page_no ili šta god se koristi, kod drugog rešenja copy-paste text.

Kod drugog rešenja je mnogo lakše promeniti strane, na primer, ako želim da se prva strana spoji sa drugom, i da umesto 3 sada ima 2 strane, samo se obriše taj marker i sve je spremno, kod prvog rešenja bi morao da se kopira tekst 2 strane i ubaci u prvu...

Generalno, oba rešenja imaju svoje prednosti, glavno pitanje je ovde koliko se često menja taj sadržaj. Ako se ne menja često, ja bih išao na prvo rešenje.

ivanhoe
25. 09. 2006., 18:16
Kod prvog rešenja, gde je svaka strana poseban record, treba obratiti pažnju na pretraživanje jer može da se desi da za isti query izbaci recimo 5 rezultata, a svih 5 su isti tekst. Meni bi to smetalo, ali to ne mora da bude bug, može da bude i feature.


da, good point... mada to moze lako da se resi, jer svaka strana mora da ima neko polje u bazi na osnovu koga ce se znati da je to strana koja je deo tog i tog dokumenta. To pruza mogucnost da search radis sa distinct document_id, tako da se za svaki document vrati samo jedan rezultat, tako da nije neki problem.

Uzgred, nisam o tome pre razmisljao, ali meni se bas dopada mogucnost da kad searchujes nesto dobijes bas direktno stranu na kojoj to pise (po mogucstvu highlighovano zutim :) ), a ne da dobijes prvu stranu, a ono sto tebe zanima je tek na 10-toj. Recimo ja bih to resio tako sto bih radio group by document_id, i onda rezultate prikazao kao:
-neki naslov (strane 4, 5, 12)
-neki drugi naslov (strane: 3, 7)

Deluje mi kao bas prakticna stvar...

Pedja
27. 09. 2006., 09:18
Postoji jos jedna opcija, da se napavi editor koji ce korisniku omoguciti teksta kao integralnog a kada tekst smesta u bazu da ga izdeli u vise strana (bilo po duzini teksta bilo po uneetim oznakama kraja strane).

Takodje bi valjalo koristiti preciznije termine, posto strana u pirncipu oznacava prsotor u koji se smesta odgovarajuci sadrzaj, pa ako sadrzaja ima previse on prelazi na sledecu stranu.

Ako se radi o podeli na logicne celine teksta, onda se tu pre moze govoriti o delovima, podnaslovima ili necem slicnom.

dee
27. 09. 2006., 18:35
uneses tekst u komadu, ali sa markerima prema kojima ce ti aplikacija za unos prepoznat strane (i samo za to ti trebaju). u bazi stavis article_id | article_page | page_content. kod ispisa mozes prikazat bilo cijeli clanak bilo stranu koju user trazi, izmjena redoslijeda je isto jednostavna, a kod searcha vratis i id clanka i na kojoj strani se u clanku unos nalazi...