Citat:
A šta je sa uštedom prostora. Zar nije bazi jeftinije skladištiti autonumber polje nego stvarni tekst kada se koristi recimo combo box. Ili je ta ušteda minorna u odnosu na komplikacije koje se mogu dobiti korištenjem autonumber-a.
Pitanja su na mestu. Idemo redom.
1) Usteda prostora je najmanje vazan factor. Danas je 2013 godina, RAM se meri u gigabajtima, proctor na disku u terabajtima, proctor nije skup - prema tome, to nam je poslednja briga. Ovo ne znaci da treba cuvati opcije tipa "Popravka kucne instalacije vodovoda, od bakarnih cevi precnika 15 mm sa probom na pritisak". Ako se vec cuvaju kodovi umesto punog teksta, zasto kodovi ne bi bili tekstualni? Po cemu je kod 1 bolji nego kod GUK? Prosecan korisnik tvog sistema za pracenej diajebata zna sta je GUK, a kod 1 treba da trazi ili pokusa da zapamti. Ne znaci da ne mogu brojevi da se koriste, sve je stvar procene. Pazi, rekao sam brojevi, ne obavezno autonumber. Autonumber je samo precica, naoko oslobadja programera nekih posolva - autonumber dozvoljava programeru da bue lenj. To sto je programmer lenj, nije najgore. Najgore je sto je programmer, barem u Accesu, istovremeno i projektant baze podataka. Lenjost projektanta baze je mnogo opasnija stvar nego lenjost programera (onog ko pise kod za front end). Cinjenica da se autonumber moze automatski dodeliti i da je kvazi jedinstven, ohrabruje lenjost na nivou projektovanja baze. Tako se cesto zbog autonumbera zanemari uopste razmisljanje o nekakvom prirodnom kljucu. To nije samo teorijsko naklapanje. Autonumber dozvoljava ovakve stvari:
Code:
CREATE TABLE MOjaKodnaTabela (Kod autonumber, Opis)
INSERT INTO MOjaKodnaTabela (Kod,Opis) VALUES (1, 'tra lal la')
INSERT INTO MOjaKodnaTabela (Kod,Opis) VALUES (2, 'tra lal la')
INSERT INTO MOjaKodnaTabela (Kod,Opis) VALUES (3, 'miki maus')
INSERT INTO MOjaKodnaTabela (Kod,Opis) VALUES (4, 'tra lal la')
Uneli smo cetiri razlicita jedinstvena koda, tri duplikata u opisu. Istina je da se ovo moze desiti i kada su kodovi tekstualni, ali se u praksi to iz nekog razloga desava mnogo redje. Zasto, ne znam, ali je mnogo redje. Verovatno zato sto dodeljivanje kodova nija automatsko, nego neko mora da sedne i da razmisli i konstruise kod, rucno ili programski. E taj deo, razmisljanje o konstruisanju koda nedostaje kada se koriste autonumbers. Sve se nekako prepusiti kompjuteru i Microsoftu, a nijedno od to dvoje nije bas pametan entitet. Kad se koristi autonumber, obicno je to JEDINO sto red u tabeli cini jedinstvenim, sve ostalo se zaboravi ili zanemari. Ako ne bi zaboravili da pronandjemo prirodni kljuc, i da razmisljamo o ostalim ogranicenjima, mozda bi se pokazalo da nam autonumber i ne treba jer nam nista ne govori o predmetu posmatranja. A ako nam nista ne govori o predmetu posmatranja, onda je to suvisan podatak.
Opet, ne kazem da ne treba koristiti autonumber i numericke kodove, ali treba biti svestan sta se time dobija a sta gubi. I ne treba nikako zanemarivati pravila procesa projektovanja. Nazalost, zanemarivanje procesa projektovanja je jako rasireno u praksi, a autonumber nam stvara lazni osecaj sigurnosti da smo eto nesto uradili po pitanju odredjivanja kljuceva.
Pravilno konstruisana kodna tabela, ako hocete da koristite brojeve, izgleda ovako:
Code:
CREATE TABLE MojaKodnaTabela2
([Kod] int NOT NULL
, [Opis] text NOT NULL
, PRIMARY KEY ([Kod])
, UNIQUE [Opis])
Sad bar necemo moci da unesemo isti opis dva puta. Sad imamo i dva kljuca, od kojih smo jedan izabrali da bude primarni. Koji cemo kljuc izbrati da bude primarni, sasvim je svejedno. Primetite da bismo imali kljuc i da nismo uveli kolonu Kod u igru.
Problemi sa kodovima se ne zavrsavaju time sto necete da upotrebite autonumber. I ovo se desava u praksi:
INSERT INTO MojaKodnaTabela2 (Kod, Opis) VALUES (1,'Jabuka')
INSERT INTO MojaKodnaTabela2 (Kod, Opis) VALUES (2,'Kruska')
INSERT INTO MojaKodnaTabela2 (Kod, Opis) VALUES (3,'Sljiva')
Onda se negde u neki system za prodaju unose kodovi za prodatu robu. Posle godinu dana s eneko nasali i promeni opise kodova:
UPDATE MojaKodnaTabela2 SET Opis = 'Lubenica' WHERE Kod = 2
Jabuke koje smo godinu dana prodavali jednim potezom pera postale su lubenice. Da smo tabelu konstruisali ovako, to se ne bi desilo:
Code:
CREATE TABLE MojaKodnaTabela2
([Kod] text(3) NOT NULL
, [Opis] text(25) NOT NULL
, PRIMARY KEY ([Kod])
, UNIQUE [Opis]
, CHECK [Kod] = LEFT([Opis],3)
)
Sad sam uradio jeres - [Kod] je postao tekst polje, pa jos i izracunato polje. Jeste izracunato polje, ali imamo i CHECK (Validation Rule na nivou tabele) koji zahteva da [Kod] bude TACNO izracunat. U tom slucaju, ovako bi zigledali kodovi:
INSERT INTO MojaKodnaTabela2 (Kod, Opis) VALUES ('JAB','Jabuka')
INSERT INTO MojaKodnaTabela2 (Kod, Opis) VALUES ('KRU','Kruska')
INSERT INTO MojaKodnaTabela2 (Kod, Opis) VALUES ('SLJ','Sljiva')
Pretvaranje jabuke u lubenicu ne bi proslo:
UPDATE MojaKodnaTabela2 SET Opis = 'Lubenica' WHERE Kod = 'JAB'
Validation rule ne dozvoljava ovakvu transakciju. ne kazem da je uvek ovako jednostavno konstruisati tekstualni kod. Vazno je da vas nesto natera da o tome razmisljate, pa kakvo god resenje donesete, bice bolje nego pobeci u laznu sigurnost autonumbera ili sekvencijalnih brojeva.
Postoje bar dva slucaja koriscenja izracunatih kodova. Jedan je jedinstveni maticini broj, koji u sebi sadrzi datum rodjenja i oznaku opstine rodjenja. Drugo je VIN (vehicle identification number), serisjki broj vozila. VIN u sebi sadrzi proizvodjaca, marku vozila, model, godinu proizvodnje, mesec proizvodnje. Ako se baza pravilno konstruise, veoma je tesko podneti tudji maticni broj ili tudji VIN broj. I VIN i JMBG imaju kontrolnu cifrumoja sprecava unos nepostojecih (nepravilno konstruisanih) brojeva.