praksa prilikom kreiranja vezanih tablica

Problem je vise semanticke prirode.
- Recimo da imamo tablicu sa stavkama racuna i tablicu artikala
- u tablicu stavki racuna ukucavamo sifru artikla,cijenu,kolicinu,...
scenarij je da korisnik baze nakon nekog vremena promjeni naziv artikla ili ga izbrise pa se isti vise ne bi mogao pozvati
ili bi se pogresno registrovao za stavke racuna koje su unesene prije izmjene.

Molim Vas da prodiskutujemo o vasim iskustvima.. kako rjesavate vi ovaj problem?
arhivirate li kompletno sve elemente artikla za stavku racuna .. ili samo sifru i cijenu.

Pozdrav

Potpis

Give me six hours to chop down a tree and I will spend the first four sharpening the axe.

[Quote]scenarij je da korisnik baze nakon nekog vremena promjeni naziv artikla ili ga izbrise pa se isti vise ne bi mogao pozvati
ili bi se pogresno registrovao za stavke racuna koje su unesene prije izmjene.[/quote]

Scenario je pogresan. Svaki artikl cija je sifra prenesena u tabelu Stavke, ne moze se i ne bi smeo da se brise iz tabele Artikli. Zato postoji FOREIGN KEY, da spreci ovo sto ne sme da se desi.

Ti iam s dva pitanja: 1) da se artikl penzionise (ne koristi se vise) i 2) da se artikl preomenuje

Zahtev da se neki artikl penzionise je validan zahtev. Ako neki artikl nije vise dostupan, povucen iz prizvodnje, sta bilo, onda u stvari hocemo da kazemo 'pocevsi od datuma D1 artikl A vise ne sme da se pojavi u tabeli Stavke'. Ovaj zahtev se tesko realizuje u samom SQL-u, ali se lako realizuje u aplikaciji - ne dozvolis unos artikala koji imaju flag Neaktivan = TRUE. Ovo dobro radi u praksi i mnogo se koristi. U samom MS SQL moze da se napise korisnicka funkcija koja proverava dostupnost artikla, pa se funkcija ugradi u CHECK constraint. STvari se komplikuju dodatno ako artikl moze da se povlaci i vraca u prodaju vise puta. Onda moranmo da pratimo stanja artikla. Stanje ima dve vrednosti (Aktivan, Neaktivan) i samo aktivni artikli smeju da se unesu u Stavke. Uslov bi glasio: "Da bi artikl bio unesen u tabelu STavke, datum Stavke.Datum mora biti u periodu kada je Artikl aktivan". I ovo je tesko da se izvede u SQL u ovom momentu, pa s euglavnom to odradjuje na nivou aplikacije, u nekoj proceduri koja vrsi INSERT u Stavke. Tek ako su svi uslovi ispunjeni, procedura izvrsava INSERT.

Promena naziva ima dva slucaja. Slucaj 1 - ispravka greske. Ako se artikl pod sifrom 'A1' zove 'Jabuka Delises' i mi greskom ukocamo 'Jabkkka Desiles' onda naziv mora da s promeni, da bi se ispravila greska. Slucaj 2: recikliranje sifre. Ako zelimo da recikliramo sifru 'A1', koja je ozbnacavala 'Jabuke', pa da tu istu sifru koristimo za artikl 'Lubenice', to nije dozvoljeno, to je opasno. Ne bih se cudio da i zakon o knjigovodstvu to ne dozvoljava. Opasno je zato sto takvom promenom, sve 'Jabuke Delises' koje smo u proslosti prodavali, pojavice se na izvestajima kao 'Lubenice'. Svrha knjigovodstva je da se zabeleze cinjenice o poslovnim transakcijama. Baze podataka samo podrzavaju taj proces i mi nemamo pravo da menjamo knjigovodstveni proces zato sto je tako zgodno bazi ili programeru.