Po relacionoj teoriji loša ideja. Ako svaki autor unosi svoj komentar što je predpostavljam cilj zadatka onda se pristup polju autor_id kontroliše iz roditeljske tabele Autor(autor_id (PK), autor_username.....). Nikakva moguća brzina pristupa ne treba da te zavara. Redudanca je opasnija od sporosti. Ako ti se ikad desi da pored teksta bude stajalo tuđe ime umesto ime pravog autora (moguće greške redudantnosti podataka), osetićeš šta je neprijatnost.

Pa da...To krši pravila relacione algebre ali sam ipak hteo da čujem da li neko ovo praktikuje i zašto i kakva su iskustva ?

Video sam na par mesta da se to radi (phpbb forum npr. a verovatno ima onda i u mnogim drugim projektima), pa mi delovalo tu i tamo primamljivo

Jedina stvar zbog koje ne bih ovo radio je baš to što si pomenuo da nije po relacionoj teoriji, pa kad bih išao tako redom,
ispalo bi da koristim RDBMS a da ne koristim to što on pruza i plus ne igram po pravilima koje on nameće...

Da to se radi - namerno narušavanje 3NF ili 4NF. Onda je odgovornost aplikacije da održi konzistentnost. Ono što bi trebalo da bude relativno bezbolno je da se nad takvim poljima ne radi nikad UPDATE. Na primer, ako hoćeš da ubaciš USERNAME, zabraniš da se ikada menja USERNAME u tabeli u kojoj bi se inače on čitao preko USERID.
Fini je relacioni model, ali kad performanse zahtevaju, zažmuriš na jedno oko.

Primer iz realnog života: na tabeli naloga i tabeli stavki imam polje DATUM_NALOGA. Pravilo u aplikaciji je da sve stavke istog naloga imaju isti DATUM_NALOGA kao i u tabeli NALOG (čista redundansa). E sad, kada hoćeš report po datumu naloga iz tabele od 500 miliona stavki i 100 miliona naloga, onda ta redundansa puno znači.

Još jedan dodatak: nemoj ovo da shvatiš kao da ti ja predlažem da u tvom primeru uradiš takvu stvar. Sa nekoliko hiljada postova i nekoliko stotina autora nećeš videti nekakav dobitak, a potencijalna šteta postoji. Ovakve stvari radiš kada imaš zaista jak razlog.

_{[Ovu poruku je menjao djoka_l dana 09.04.2009. u 15:00 GMT+1]}

@Tudfa: Gstsbi ti je rakoa zasto ne valja, a Djoka_i te lepo savetuje. Sve se moze, ali nije bas pozeljno ako bas ne moras.

U 99% slucajeva u praksi, ljudi urade redunsdansu je ne znaju drugacije ili misle da je to brze. Da li je brze, to treba dokazati. Obicno se ni ne proba druga varijanta (normalizovano) pa nema dokaza, ali zato neko 'zna' da ce sa redundansom biti brze. Hajde da to prihvatimo. Neka je brze sa redundansom, i to znacajno. Problem je sto se onda ne ucini nista da se cuva integritet podataka. Lepo rece Djoka_I:
Problematicna rec je 'bi trebalo'. Sta bi bilo, kad bi bilo.... Ne moze 'trebalo bi' nego MORAS da sprecis mogucnost promene takvog prenesenog podatka. To moze da se uradi na razne nacine, zavisno od sistema na kome radis.

Najprostije je da napravis jos jedan FK, da ti iz glavne tabele ne proverava samo AutorID, nego (AutorID,Ime Autora). Ovo zahteva da u prvoj tabeli imas jos jedan unique index. Pored PK (AutorID), treba ti jos jedan 'super key' = (AutorID, ImeAutora) sto zahteva jos jedan index na glavnoj tabeli. Onda u tabeli gde imas redundansu treba da stavis da je ImeAutora NOT NULL i FK koji referencira (AutorID, ImeAutora). Onda ti treba trigger koji ce da garantuje da je ImeAutora prenseno u tabelu sa redundansom. Kad sve to uzmes u obzir, zaboli te glava, pa vecina ljudi ne uradi nista od ovoga. I onda se izgubi data integrity. A ako se sve ovo i uradi, mozda se zbog odrzavanaj dodatnog indksa i FK i trigera, mozda se nesto drugo u celoj shemi uspori. To sve je da zastitis 'child' tabelu. medjutim, sta ako se ime autora u parent tabeli promeni? To se desava. Treba ti mehanizam da taj update prenses na child tabelu. A rekosmo da ne dozvoljavamo UPDATE u child tabeli........ I krug se zatvorio, farbajuci pod saterali smo sebe u ugao daleko od vrata.

Znaci, treba mnogo razmisljanja, planiranja, testiranja i pazljivog odmeravanja sta se time zaista dobija. treba se zapitati da li zaist program koji sabira 5 miliona stavki po datumimna zasta mora da se izvrsi za 0.001 sekundu ili mozda moze i dve sekunde? Vreme da se uspostavi konekcija sa SQL serverom i podaci posalju na klijent je obicno mnogo vece nego vreme izvrsavanja kverija, ako je baza lepo projektovana (normalizovana). razlog sporosti je obicno komplikovani kveri, sto najcesce proizilazi iz lose projektovane baze, a moze i zbog lose odrzavana baze (reindksiranje, statistika). I onda, problem koji je nastao zbog lose projektovane baze pokusavamo da resimo tako sto bazu jos gore pokvarimo denormalizacijom.

Ukratko ako ne moras, nemoj to da radis, a sve su sanse da ne moras. Ako je pitnje akademske prirode, batali, jer nema nista akademsko u razrusavanj necega sto i nije sagradjeno do kraja.

Moguće je da ja nisam dobro shvatio namenu aplikacije. Za poslovne aplikacije tipa transakcionih baza OLTP, moj odgovor bi bio prikladan. Međutim ako je namena aplikacije čisto analitička ili je baza orjentisana
ka skladištu podataka (DW), da se nad njom nadgradi OLAP aplikacija, onda je narušavanje normalnih formi (denormalizacija) čak i poželjna u gradnji takozvane tabele činjenica (fact table). U ovom drugom slučaju obično postoje dve aplikacije: transakciona i analitička. Ona prva služi ovoj drugoj.

Ljudi hvala na odgovorima , naručito Zidaru, od čijeg mi se odgovora još uvek malo muti u glavi, al to me interesovalo

Ma ja sam uvek bio za školsku varijantu, i dok sam studirao nisam ni znao za ovo. Relaciona algebra i tačka.
Onda sam uzeo da pogledam kako izgledaju neke nazovimo naprednije aplikacije, kad ono mnogo duplih polja.
I od tada me stalno kopkalo, zašto to ljudi rade kad je odavno definisano šta i kako od strane Codd-a

@Getsbi

Kapiram, drzim se ja pravila, i onda lepo nema da mislim.
Sajt koji pravim nije nešto velik ili namenjen za neki mnogo velik saobraćaj
(mada upita ima, postoje registrovani korisnici, moderatori, admini, pretrage...)
tako da važi ono što si rekao u prvom postu.

Svidja mi se ovo 'nazovimo'. Pitanje je ko je to nazvao aplikaciju naprednom. Uglavnom programeri. Pa jos ako su primenjene najnovije tehnike programiranja i algoritmi, platforme i paradigme (gde me nadje ;-), covek se lako uzbudi kad radi ono sta voli. Sto je i razumno, svako je ponosan na ono sto radi, i treba da bude.

Programiranje nije lak zanat, to ne moze svako da radi. Treba mnogo talenta i mnogo rada. I usudjujem se da kazem, za razliku od recimo muzike, sam rad nije dovoljan, treba mnoogo i talenta. Uz mnogo vezbe moguce je nauciti da citas note i da svaku notu odsviras kako treba. To moze i kompjuter. I zvucace pristojno. Nece biti kao kad slusas Ivu Pogorelica,ali ce nuvezbanom uvu zvucati pristojno. Kod programiranja to ne moze. Neko moze da nauci komande i sintaksu i algoritme i opet da pravi kilave programe, u nedostatku talenta. I to korisnik naravno odmah primeti, uvezban ili neuvezban.

Situacija se pogorsava kad se programeri upuste u tudji posao - baze ne treba projektuju programeri nego neko ko to ume da radi. Isto kao sto operacije na mozgu ne rade ocni lekari i neuro hirurzi ne mere ocni pritisak. A razlika izmedju ocnog lekara i neuro hirurga mnogo je manja nego izmedju objektnog programera i specijaliste za relacione baze. Lose projektovane baze zahtevaju programere genijalce da bi se uopste nesto napravilo sto lici na aplikaciju. I tu dolazimo do absurda. Lepo projektovane baze zahtevaju manje programerskog napora nego lose projektovane, pa neki mozda programeri ne uzivaju u takvom poslu. Ako je baza lose uradjena, onda proramer moze da zablista i pokaze svoj majstorluk. Stalno se zaboravlja da korisnik niti vidi sta je u kodu niti ga interesuje kakv ste pametan metod ili algoritam koristili. Njega interesuje ono sto vidi i moze da klikne. Ne mozete nesto proglasiti naprednim samo zato sto ste napisali briljantan kod. To jos uvek ne znaci da ce ceo sistem da radi dobro. Dobro = ono sto korisnik ocekuje, i korisnik i samo korisnik je merodavan da ocenjuje kvalitet onoga sto smo mu dali.

I ceo Office 2007 je 'nazovim' napredna aplikacija. Tako bar Microdoft pokusava da nas ubedi......

Getsbi je naravno u pravu za OLAP sisteme. OLAP sistemi nemaju veze sa relacionim bazama. I kod njih vreme izvrsavanja nije kriticno. A cela prica je krenula od toga da se mora nesto denormalizovati da bi se dobilo na brzini. Eto kontradikcije. Denormalizujemo da bi bilo brze i zavrsimo na OLAP koji je po definiciji spor.