Jedna tablica sa kontrolim atributom ili dvije tablice?

Imam tablicu glavna_knjiga (id, konta_broj, temeljnice_id, partneri_id, proknjizeno (bit)).
Zanima me koliko može utjecati na performanse to što će se u većini pregleda i ispisa u selectu koristiti where proknjizeno!=1, budući da bi ta tablica mogla sadržavati nekoliko 100k zapisa?

Ideja je napraviti tablicu 1: temeljnica_stavke (== glavna_knjiga_neproknjizeno) i tablicu 2: glavna_knjiga (== glavna_knjiga_proknjizeno).
Tada bi se pomoću triggera nakon update-a atributa prve tablice proknjizeno u True ubacili zapisi u drugu tablicu i za većinu pregleda koristila bi se druga tablica (bez where... u selectu).

Dakle, pitanje je koristiti prvu soluciju sa where (i dodati index za taj atribut) ili druga solucija - dvije odvojene tabele?

Pozdrav.

moj predlog bi bio View (sa uslovom proknjizeno=1) , koje ce posle biti korisceno, umesto da trigerom radis drugu tablicu.
To view se moze indeksirati vec po potrebnim uslovima, ali osnovni Index bi bio Clusterd index po Id.

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

Hvala vam na odgovorima i zanimljivom štivu :)

Izvinjavam se zbog nekompletne strukture (naravno, postoji tu mnoštvo atributa: BrojKonta FK, Duguje, Potrazuje, BrojTemeljnice FK, DatumDokumenta, Opis,... pa i DatumProknjizeno). Zapravo, svjesno sam išao na denormalizaciju tablice glavna knjiga i dodao atribut proknjizeno u glavnu knjigu, kako bi izbjegao join-ove sa tablicom temeljnice. Tu se slažem da bi ta tablica mogla imati "pomoćnu" tablicu sa stanjima i datumima, međutim onda će za pregled glavne knjige biti potrebna 2 join-a (opet pitanje performansi?)

Budući da moja aplikacija ima zadaću zamijeniti tuđu aplikaciju čiji su performanse dosta loše možda previše brinem o performansama sql query-a.