@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:
Citat:
Ono što bi trebalo da bude relativno bezbolno je da se nad takvim poljima ne radi nikad UPDATE.
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.
Ponavljanje pojedinih polja u razlicitim tabelama
