|
Prikazivanje članaka na više strana
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: |
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. |
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š. |
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... |
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? |
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. |
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. |
Citat:
|
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. |
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...
Citat:
Citat:
Citat:
|
| Vreme je GMT +2. Trenutno vreme je 08:51. |
Powered by vBulletin® Verzija 3.6.8
Copyright ©2000 - 2024, Jelsoft Enterprises Ltd.
Copyright © DevProTalk. All Rights Reserved.