Ako ja postavim pitanje da li u nekoj prostoriji da napravim orman-regal sa 50-100 fijoka ili nekoliko oramarića sa 10-15 fijoka, uslediće sa tvoje strane sledeća pitanja: Koja je namena prostorije? Šta se čuva u fijokama? Da li je istorodan ili raznorodan materjal koji se čuva? i niz sličnih pitanja.
Dakle odgovor na pitanje: "Ravna tabela ili relacioni model više tabela?" bio bi: "Zavisi od projektnog zadatka (namene, broja mogućih entiteta, eventualnih veza između njih, koje proističu iz poslovnih pravila ........"
Prednosti jedog nad drugim mogu da se razmatraju samo u kontekstu određenog zadatka. Zadatak mora da bude iscrpno opisan i definisan sa istaknutim svim zahtevima korisnika i resursa. Naknadno dodavanje zahteva može, a ne mora da naruši koncept.

Covek je sasvim dobro objasnio sta ga interesuje, samo treba znati procitati.

Dilema je vrlo cesta: da li sve podatke iz jedna tebele koji su odredjeni istim primarnikm kljucem podeliti u vise tabela koje su medjusobno u vezi 1:1, to jest, da li bi se time dobilo na performansama.

Odgovor je: to zavisi od baze. Neke baze se dobro snalaze bez obzira na obim podataak ujednom slogu a neke ne.

Neću reći ništa novo - zavisi od baze (podataka).

Odgovor na pitanje zavisi od strukture podataka - obično se u tabelama sa mnogo kolona nalazi i mnogo "NULL-abilnih" kolona. To je meni uvek signal za potencijalni problem u strukturi podataka. Često takve ogromne tabele i treba da se razbiju u manje tabele. i da tom prilikom čak nastane 1:0 veza među njima (VIEW-om i JOIN-ovima se posle ove tabele lako "fletuju").

Dalje, zavisi i od prava pristupa podacima. Osetljive kolone koje netreba baš svako da vidi možeš da prebaciš u drugu tabelu i nad njom primeniš strožija pravila pristupa.

Naravno zavisi i od performansi sistema - ako se radi o maloj količini podataka teško ćeš primetiti razliku u korišćenju jedne u odnosu na dve tabele (čak i da se te dve tabele fizički nalaze na posebnim hard diskovima).

Ono što je sigurno - sistem sa više tabela je teži za "programiranje" (što ne znači da takav sistem treba izbegavati).

Ja sam za vise malih tabela,jer kao sto si i sam rekao u toj velikoj bi koristio samo 10-20% kolona!Mislim da bi u slucaju vise tabela dobio dosta na performansama sistema!

Chachka je kazao:
Ovde moram da se donekle ne slozim. Mozda je bolje reci "sistem sa flat tabelama je 'laksi' za programiranje samo u nekim specijalnim slucajevima". Ako "sistem" posmatramo kao celinu sa mnogo funkcija koje treba da obavi, vecina funkcija koje sistem treba da obavi je mnogo laksa za programiranej ako je baza lepo normalizovana (mnogo tabela sa malim brojem kolona). Kazem "vecina", a to bi bilo izmedju 90% i 99% funkcija, zavisno od sistema, a prema mom iskustvu.

Znaci, ako se fokusiras na jednu specijalnu operaciju koju sistem moze da obavi, onda ti se moze uciniti da je jedna flat tabela 'bolja' nego normalizovana baza. To su situacije tipa "ali moj klijent hoce da unese plan za 12 meseci horizontalno, svaki mesec jedna kolona.." i slicno. U redu je da klijent tako hoce da UNOSI podatke. Nije u redu da se tako podaci organizuju. Dobar programer ce napraviti lako da klijent VIDI na ekranu ono sta je tarzio da VIDI (makar i za potrebu unosa), a da sve bude savrseno lepo normalizovano u pozadini. Naglasak je na "dobar programer". Da li je lako? Ne uvek, ali dobri programeri su obicno placeni dovoljno para da od njih ocekujemo da nauce da u svom programskom jeziku korisniku prikazu normalizovane podatke u bilo kom obliku.

Fokusiranje na jednu specijalnu funkciju (obicno unos ili prikaz podataka) i gradjenje ostatka sistema oko te funkcije, nije dobra ideja. Sta ce se sve od sistema traziti u buducnosti i nije moguce 100% predvideti na pocetku. U tome je glavna vrednost normalizovanih baza podataka - one omogucuju strahovitu fleksibilnost, i na starni sa podacima, i na front endu. Naravno, u celoj guzvi uvek ima nesto za sta bi flat tabela bila 'laksa' (ali ne i 'bolja', samo 'laksa') i to prividno, za programiranje jedne jedine funkcije sistema. A programer koji bezi od 'teskog' resenja ili je lenj ili ne zna svoj posao. Kako god okrenes, ne valja

:-)