Chachka je kazao:
Citat:
Ono što je sigurno - sistem sa više tabela je teži za "programiranje" (što ne znači da takav sistem treba izbegavati).
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
:-)