Kad god mogu da od kandidata za PK odaberem prirodni ključ (nešto iz realnog šivota), ja to uradim. Recimo skraćene oznake jedinica mera: kg, lit, met, kom..... (tabele sa relativno malim brojem zapisa).
No kako se to retko dešava onda naravno kao i svi pribegavam veštačkim ključevima: PartnerID, ArtikalID, MestoID.....
Kad ne želim da upravljam dodeljivanju brojeva u okviru ID broja, recimo partnera, onda to prepuštam Access-u i tipu polja Autonumber.
Kada mi je važno da pratim redosled dokumenata, u slučaju ozbiljnijeg modela podataka koji se odnosi recimo na finansijsko knjigovodstvo gde postoji veći broj vrste dokumenata, onda izbegavam Autonumber i pribegavam rešenju koje je pomenuo kolega domaci_a_nas. Tada pravim zasebnu tabelu sa vrstama dokumenata i maksimalnim brojem u okviru vrste. Ovde ide sve ono što podrazumeva praćenje jedne takve evidencije. Primer: Tabela finansijskih naloga za knjiženje. Primarni ključ je složeni. Numeracija je u okviru vrste dokumenta. Ovde koristim tip Integer. Može i Long Integer, ako su vam predpostavke da će "n" biti veće od 36000.
BL/1.........BL/n -------- blagajna
TR/1........TR/n -------- tekuci racun
UK/1........UK/n --------- ulazna kalkulacija
.
.
E sad, iskustva su različita. Afiniteti takođe. Uvek može da se čak i loše projektovana tabela izgura kroz aplikaciju ako postoji znanje iz programiranja, što naravno ne preporučujem. Sećam se jednog mog profesora koji je govorio. „Nemojte da radite kao što ja radim, već kako vas učim da treba.“
Što se tiče pitanja koje je postavio kolega lukeguy “...više godina u jednoj bazi...”, tu koristim sledeću logiku. Ako je u pitanju izolovani poslovni problem, tipa: „Praćenje faktura“ ili „Materjalno knjigovodstvo jednog magacina“, onda uvodim godinu u broj dokumenta i dozvoljavam podatke više kalendarskih godina u jednoj bazi. Kada je u pitanju Finansijsko računovodstvo (knjigovodstvo sa bilansima), tada držim svaku godinu u zasebnoj bazi ili bolje rečeno svake godine otvaram novu.
Razlozi:
1. sve je proknjiženo,
2. urađen završni račun,
3. automatski prenešena stanja po kontima u drugu godinu.
4. ne postoji potreba ( a nije ni dozvoljeno) da se podaci ažuriraju.
Ovo sve važi za OLTP aplikacije kojima se mi ovde bavimo. Da je u pitanju OLAP aplikacija, sigurno bih sve držao u jednoj bazi i insistirao na jačem hardveru. Kod OLAP aplikacija predpostavke su sledeće: Data Warehousing (skladište podataka), denormalizovan podaci, definisane hijerarhije, kreirane agregacije.... a to pre svega uslovljeno potrebom menadžera da mogu dobiti svaku realnu informaciju u što kraćem vremenu iz kompletnog višegodišnjeg poslovanja.
Registrovani: 3 ( Ultrena, Seyokiller, Pirossi )
Polje AutoNumber kao 01/08