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.