Tabela deluje nekompletno, pa je i pitnje pomalo nekompletno. Ovo j predlozena struktura tabele:
glavna_knjiga (id, konta_broj, temeljnice_id, partneri_id, proknjizeno (bit)).
Pitanje je u stvari bilo 'da li ce kveri biti efikasan ako je WHERE po bit polju' Odgovor, kratko - nece. Mislim da se ne moze indeksirati po bit, ali i ako moze, distribucija (nula,jedan) ne dozvoljava efikasne algortme pretrazivaja, pa SQL Query optimizer uglavnom skenira celu tabelu i ignorise index. Stoga ni obican view nece biti efikasan. Indeksiran view isto nece biti efikasan,kako god ga indeksirali. View povlaci podatke iz tabele a taj korak ce uvek biti neefikasan. Kako bilo da bilo, view, indeksiran ili neindeksiran bolji je i brzi od trigera i Nada je to 100% u pravu.
Sva sreca je da 100K zapisa (sto hiljada) i nije neki veliki broj, pa je diskusija o efikasnosti u omenu teorije. U praksi se nece osetiti neka razlika u brzini. View je puzdaniji nego triger, i uvek radi, a triger ponakad i zakaze. Tu je sustinska razlika.
Sad ono sto je u stvari pravi problem sa predlozenom tabelom. Zasto je tabela nepotpuna? Zato sto nedostaje datum proknjizenja. Imati samo bit signal za jeste/nije proknjizeno nije dovoljno, a i zakoni o knjigovodstvu to ne prihvataju. Ako pak dodas kolonu DatumKnjizenja, onda tabela vise nije normalizovana. Neko tamo pravilo kaze da svaka kolona se da zavisi samo i samo od kljuca (ID). Kolona DatumKnjizenja ne zavisi samo od ID. Zavisi i od kolone Proknjzeno. Samo ako je Proknjizeno = 1 onda DatumKnjizenja mora biti prisutan, i obrnuto, ako je datum knjizenja prisutan, bit mora biti jednak jedinici. Sve ostale kombinacije su nedozvoljene. Zatim, datum knjizenja ne bi smeo da bude pre datuma temeljnice, a koji se nalazi cak u nekoj drugoj tabeli. Dodavanje datuma knjizenja ocito komplikuje stvari i zato ga mnogi izbegavaju. To nije dobro. Jos gore je ako covek nije ni svestan da se sve ovo desava ili se moze desiti.
Mozda treba razmisljati drugacije. 'Proknjizeno' je samo jedno od stanja kroz koja prolazi temeljnica. Ostala stanja, na primer, mogla bi biti "Primljena", "Kontrolisana","Odobrena" da bismo je mogli proglaisiti "proknjizenom". Svako to stanje imalo bi svoj datum, koji bi morao biti veci ili jednak od datuma prethodnog stanja, ID osobe koja je potvrdila posmatrano stanje. Ovakvom organizacijom bi glavna knjiga verovatno postala view. Ako te interesuje, pretrazi forum MS SQL, baze podataka i Access, kljucne reci 'promene stanja' i naci ces korisnog materijala. Bilo je nekoliko lepih diskusija gde se ponesto o pracenu proemna moze naci. Kljucna rec - NadaVesela
Jedna tablica sa kontrolim atributom ili dvije tablice?
