DevProTalk

Forumi IT profesionalaca
web development, web design, e-business, SEO


Idite nazad   DevProTalk > Web development i web aplikacije > Programiranje
Želite da se reklamirate ekskluzivno na ovoj poziciji? Javite se

Programiranje Java, Perl, VB, ASP, .NET, C, C++, Pascal, Delphi Sponzor: VIP izazov 3

Odgovori
 
Alati teme Način prikaza
Staro 24. 09. 2006.   #1
Dzordz
Diskutabilni diskutant
Wrote a book
 
Avatar Dzordz
 
Datum učlanjenja: 09.04.2006
Lokacija: Brno
Poruke: 1.113
Hvala: 36
103 "Hvala" u 74 poruka
Dzordz is on a distinguished roadDzordz is on a distinguished road
Default 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
Dzordz je offline   Odgovorite uz citat
Staro 24. 09. 2006.   #2
Ilija Studen
Direktor Kombinata
Invented the damn thing
 
Avatar Ilija Studen
 
Datum učlanjenja: 07.06.2005
Poruke: 2.669
Hvala: 44
119 "Hvala" u 64 poruka
Ilija Studen će postati "faca" uskoroIlija Studen će postati "faca" uskoro
Default

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.
Ilija Studen je offline   Odgovorite uz citat
Staro 24. 09. 2006.   #3
Alef
član
Na probnom radu
 
Avatar Alef
 
Datum učlanjenja: 17.08.2006
Lokacija: Novi Sad
Poruke: 36
Hvala: 0
0 "Hvala" u 0 poruka
Alef is on a distinguished road
Default

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š.
Alef je offline   Odgovorite uz citat
Staro 24. 09. 2006.   #4
ivanhoe
Ivan Dilber
Sir Write-a-Lot
 
Avatar ivanhoe
 
Datum učlanjenja: 18.10.2005
Lokacija: Bgd
Poruke: 5.320
Hvala: 104
2.344 "Hvala" u 583 poruka
ivanhoe je ime poznato svimaivanhoe je ime poznato svimaivanhoe je ime poznato svimaivanhoe je ime poznato svimaivanhoe je ime poznato svimaivanhoe je ime poznato svimaivanhoe je ime poznato svimaivanhoe je ime poznato svimaivanhoe je ime poznato svimaivanhoe je ime poznato svimaivanhoe je ime poznato svima
Pošaljite poruku preko Skype™ za ivanhoe
Default

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...
__________________
Leadership is the art of getting people to want to do what you know must be done.

Poslednja izmena od ivanhoe : 24. 09. 2006. u 21:39.
ivanhoe je offline   Odgovorite uz citat
Staro 24. 09. 2006.   #5
zira
Vladan Zirojević
Grand Master
 
Datum učlanjenja: 09.06.2006
Lokacija: Beograd/Trebinje
Poruke: 903
Hvala: 106
183 "Hvala" u 82 poruka
zira ima spektakularnu auruzira ima spektakularnu auruzira ima spektakularnu auru
Pošaljite ICQ poruku za zira Pošaljite poruku preko Skype™ za zira
Default

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?
__________________
Donesi.com SrediMe
zira je offline   Odgovorite uz citat
Staro 24. 09. 2006.   #6
jablan
VD IT Direktora
Invented the damn thing
 
Avatar jablan
 
Datum učlanjenja: 08.06.2005
Lokacija: Beograd
Poruke: 2.118
Hvala: 503
1.307 "Hvala" u 282 poruka
jablan je pravi dragi kamenjablan je pravi dragi kamenjablan je pravi dragi kamenjablan je pravi dragi kamenjablan je pravi dragi kamenjablan je pravi dragi kamenjablan je pravi dragi kamenjablan je pravi dragi kamenjablan je pravi dragi kamenjablan je pravi dragi kamen
Default

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.
jablan je offline   Odgovorite uz citat
Staro 25. 09. 2006.   #7
Ilija Studen
Direktor Kombinata
Invented the damn thing
 
Avatar Ilija Studen
 
Datum učlanjenja: 07.06.2005
Poruke: 2.669
Hvala: 44
119 "Hvala" u 64 poruka
Ilija Studen će postati "faca" uskoroIlija Studen će postati "faca" uskoro
Default

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.

Poslednja izmena od Ilija Studen : 25. 09. 2006. u 02:08.
Ilija Studen je offline   Odgovorite uz citat
Staro 25. 09. 2006.   #8
ivanhoe
Ivan Dilber
Sir Write-a-Lot
 
Avatar ivanhoe
 
Datum učlanjenja: 18.10.2005
Lokacija: Bgd
Poruke: 5.320
Hvala: 104
2.344 "Hvala" u 583 poruka
ivanhoe je ime poznato svimaivanhoe je ime poznato svimaivanhoe je ime poznato svimaivanhoe je ime poznato svimaivanhoe je ime poznato svimaivanhoe je ime poznato svimaivanhoe je ime poznato svimaivanhoe je ime poznato svimaivanhoe je ime poznato svimaivanhoe je ime poznato svimaivanhoe je ime poznato svima
Pošaljite poruku preko Skype™ za ivanhoe
Default

Citat:
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..
__________________
Leadership is the art of getting people to want to do what you know must be done.
ivanhoe je offline   Odgovorite uz citat
Staro 25. 09. 2006.   #9
Dzordz
Diskutabilni diskutant
Wrote a book
 
Avatar Dzordz
 
Datum učlanjenja: 09.04.2006
Lokacija: Brno
Poruke: 1.113
Hvala: 36
103 "Hvala" u 74 poruka
Dzordz is on a distinguished roadDzordz is on a distinguished road
Default

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.
Dzordz je offline   Odgovorite uz citat
Staro 25. 09. 2006.   #10
jablan
VD IT Direktora
Invented the damn thing
 
Avatar jablan
 
Datum učlanjenja: 08.06.2005
Lokacija: Beograd
Poruke: 2.118
Hvala: 503
1.307 "Hvala" u 282 poruka
jablan je pravi dragi kamenjablan je pravi dragi kamenjablan je pravi dragi kamenjablan je pravi dragi kamenjablan je pravi dragi kamenjablan je pravi dragi kamenjablan je pravi dragi kamenjablan je pravi dragi kamenjablan je pravi dragi kamenjablan je pravi dragi kamen
Default

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:
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.
Citat:
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.
Citat:
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.
jablan je offline   Odgovorite uz citat
Odgovori



Pravila pisanja
Možete ne započinjati nove teme
Možete ne slati odgovore
Možete ne slati priloge
Možete ne izmeniti svoje poruke
vB kôd je Uključen
Smajliji su Uključen
[IMG] kod je Uključen
HTML kôd je Isključen
Pogledajte forum

Slične teme
Tema Početna poruka teme Forum Odgovori Poslednja poruka
Httpool testira prikazivanje video-banera Miloje Sekulic Marketing i SEO 12 10. 11. 2008. 11:59
Prikazivanje / skrivanje elemenata u liniji moebius (X)HTML, JavaScript, DHTML, XML, CSS 3 04. 11. 2008. 09:21
WordPress plugin za glasanje članaka i objavu na naslovnoj Deki80 Sva početnička pitanja 1 22. 03. 2008. 03:18
Pozitivna strana trača Miloje Sekulic Linkovi 1 04. 10. 2007. 17:52


Vreme je GMT +2. Trenutno vreme je 01:17.


Powered by vBulletin® Verzija 3.6.8
Copyright ©2000 - 2024, Jelsoft Enterprises Ltd.
Copyright © DevProTalk. All Rights Reserved.
Mišljenja, saveti, izjave, ponude ili druge informacije ili sadržaji nastali na Sajtu su vlasništvo onoga ko ih je kreirao, a ne DevProTalk.com, tako da ne morate da se oslanjate na njih.
Autori poruka su jedini odgovorni za ovakve sadržaje. DevProTalk.com ne garantuje tačnost, kompletnost ili upotrebnu vrednost informacija, stavova, saveta ili datih izjava. Ne postoje uslovi pod kojima bi mi bili odgovorni za štetu ili gubitak koji je posledica bilo čijeg oslanjanja na nepouzdane informacije, ili bilo kakve informacije nastale kroz komunikaciju između registrovanih članova.
Web sajt može sadržavati linkove na druge web sajtove na Internetu ili neke druge sadržaje. Ne kontrolišemo niti podržavamo te druge web sajtove, niti smo pregledali bilo kakve sadržaje na takvim sajtovima. Mi nećemo biti odgovorni za legalnost, tačnost ili prikladnost bilo kog sadržaja, oglasa, proizvoda, usluga ili informacije lociranim na ili distribuiranih kroz druge web sajtove, niti za bilo kakvu štetu nastalu kao posledica takvih informacija. DevProTalk.com drži i čuva druga prava vlasništva na web sajtu. Web sajt sadrže materijale zaštićene copyright-om, zaštitne znakove i druge informacije o pravu vlasništva ili softver. Članovi mogu poslatu informacije zaštićene pravima vlasništva njihovih nosilaca i ona ostaju zaštićena bez obzira da li su oni koji prenose te informacije to naveli ili ne. Osim informacija koje su u javnom vlasništvu ili za koje dobijete dozvolu, nemate pravo da kopirate, modifikujete ili na bilo koji način menjate, objavljujete, prenosite, distribuirate, izvršavate, prikazujete ili prodajte bilo koju informaciju zaštićenu pravima vlasništva. Slanjem informacija ili sadržaja na bilo koji deo DevProTalk.com, Vi automatski dozvoljavate i predstavljate garanciju da imate pravo da dozvolite DevProTalk.com ili članovima DevProTalk.com bespovratnu, kontinualnu, neograničenu, globalnu dozvolu da koriste, kopiraju, izvršavaju, prikazuju i distribuiraju takve informacije i sadržaje i da iz takvih sadžaja koriste bilo koji deo u bilo koje svrhe, kao i pravo i dozvolu da koriste gore navedene sadržaje. Svi zaštitni znakovi (trademarks), logotipi, oznake usluga, firme ili imena proizvoda koji se pominju na ovom web sajtu su vlasništvo kojim raspolažu njihovi vlasnici.