Teorija Vs. Praksa

Svaka firma je zanimljiva na svoj način. Od ponuđenih, odlučio bih se za molersku firmu. Nekako je najbliža onome što poznajem iz vanračunarske prakse. Najviše bi mi prijala firma za pranje prozora ali da sam radnik na odmoru

Svemu ponuđenom dodao bih i stolarsku radnju.
Firma uglavnom radi izradu kancelarijskog nameštaja po narudžbi ali se povremeno javljaju potrebe za izradom ostalog kućnog nameštaja (kuhinje, kupatila, ...). Naš šef je i vlasnik firme i vrlo dobro poznaje svoj posao (dugi niz godina je bio radnik jedne veće fabrike nameštaja) ali mu je sve ostalo velika nepoznanica
Firma je do sada bila, manje-više porodična. Zbog naglog povećanja obima posla planira zapošljavanje većeg broja radnika i pozvao je nas da mu sve to "kompjuterizujemo". Ova je firma dobar primer za IS koji mora biti spreman za česte izmene sistema koje se ne mogu videti na početku.

Svakako bih iz IS izbacio sve ostale delatnosti firme kao što su nabavka, prodaja, vođenje zaliha itd. Ove delatnosti su jako bitne ali i dosta povećavaju "gabarite" projekta. Možemo ih ostaviti za kasnije diskusije.

Možda bi bilo zanimljivo ujediniti IS za ove firme kao potrebu da se napravi program koji će zadovoljiti praćenje proizvodnje u svim firmama sličnih karakteristika.

U svom prethodnom postu rekoh da je polazno pitanje zapravo dilema da li nesto u startu proglasiti entitetom (normalizovan pojam od interesa sa uvedenim "surogat ključem") iako na prvi pogled liči na relaciju. Svi koji čitaju a sigurno oni koji diskutuju pomisliše- ovaj nešto bubnu - idemo dalje.
Ali, suština je da se surogat ključ uvodi tamo gdje se ne možemo pouzdati u prirodan podskup atributa koji bi činili ključ - što je potpuno drugačije od želje da neki pojam praglasimo pojmom od interesa i da pratimo sve relacije (od interesa) koje gradi sa drugim pojmovima - kako to analiza budućeg sistema zahtjeva..
Diskusija dođe do predloga da se napravi sistem za praćenje proizvodnje firmi određenog tipa. Praćenje proizvodnje kao brojanje mrtvih ne dolazi u obzir - dakle planiranje i praćenje proizvodnje! U Japanu to rade (ili su radili do nedavno) bez računarske podrške - imaju KANBAN sistem koji je zalihe ostavio kod kooperanta pa je dostavno vozilo magacin (trpaš u njega - do linije - kad god ti je na utovarnom mjestu). Na zapadu je ta računarska oblast poznata pod MRP (material requirement planing) i predstavlja kapu jedne oblasti primjene računarske podrške. U njemu su dokumenti unaprijed pripremljeni pa bilo da su u digitalnoj formi ili papir pa je unos sveden na minimum uz obezbjeđene recoveri procedure. Dakle, i jedno i drugo je predmet detaljnih analiza, vrhunskuog poznavanja i proizvodnih procesa i mogućnosti informatičke platforme(i) za implementaciju.
Izuzev par iskrica u ovoj diskusiji, svi se drže jednog (tehničkog) dijela problema pa imaju za / protiv dugačkog join-a i šta je zadatak BP dizajna a šta se ostavlja za GUI. Sada, kada je u jednoj osobi najčešće i projektant sistema i dizajner baze podataka (ne rijetko i koder GUI npr. u Delphiju), jako je važno odgovoriti na polazno pitanje u smislu prve rečenice. Naime, projekat nije nikad dobro ( i do kraja) definisan i najčešće je riječ o otvorenom sistemu - koji odmah treba da daje neke rezultate i da se razvija dalje uz ili bez daljnje naknade ali sigurno sa što manje dodatnih napora ??? Da skratim: sve što želimo pratiti kroz ciklus: planiranje-rođenje-eksploatacija(život)-odumiranje-analiza - planiranje TREBA i MORA biti izdvojeno kao Entitet tj. dodjelit mu ID za čiju integralnost i unikatnost mi odgovaramo i koji u startu dozvoljava multiciplitet na podskupu atributa koji bi inače činili primarni (prirodni) ključ. Ovo nije zahtjev iz teorije baze podataka već iz primjene istih u podršci procesima. Ovim u potpunosti podržavam ono "tvrdoglavo" uvođenje ključeva. Poenta je u tome da je to interna stvar na nivou baze i korisnik je i ne vidi. Ako pri tome ima mogučnost da svoje transakcije nad objektima korektno izvršava - cilj je postignut !

pitanje:
popne se alpinasta do svog prozora, počne ga prati i vidi da ga zovu sa Mt.Blana. Skokne tamo, vrati se, a njegov prozor još nije do kraja opran. Uključi se u rad i na opštu radost prozor konačno bude čist

Ovo su u vremenu dvije konkretizacije relacije radnik-zadatak koje kompozitni kljuc Id_radnik, id_zadatak ne može pokriti.

Za grebenar:
Na pocetku je covek pitao ovo:


Na kraju smo dosli do tvrdnje:


Zasto ne bi mogao kompozitni kljuc (Id_radnik, id_zadatak ) da pokrije ovo? Ovim pitanjem uvodis u stvari novi entitet - "working session". Kljuc (Id_radnik, id_zadatak) u tabeli Radnik_Zadatak samo govori da je id_radnik dodeljen zadatku id_zadatak. Kad god radnik radi nesto, u nekom danu, na nekom zadatku, to je "working session" (kako se ovo prevodi na srpski?) To ne pise u tabeli Radnik_Zadatak. Meni se cini da nam treba nova tabela, WorkingSessions, gde je deo PK ono 1) sto je PK u tabeli RadniciNaZadacima. Otprilike ovako:

Teorijski nacin:
Radnik_Zadatak(Id_radnik, id_zadatak... ) PK =(Id_radnik, id_zadatak)
WorkingSessions ( Id_radnik, id_zadatak, SessionNum, Datum, KolikoSatiJeRadio) PK= (Id_radnik, id_zadatak, SessionNum)

Na ovaj nacin znam ko je dodeljen kom zadatku i koliko je kog dana radio. Jedan dan radi, drugi dan ne radi, pa opet radi.

Nacin 'iz prakse' :
RadniciNaZadacima (Radnik_ZadatakID, RadnikID, ZadatakID) onda imas PK = Radnik_ZadatakID i AK (RadnikID, ZadatakID)
WorkingSessions (Radnik_ZadatakID, SessionNum, Datum, KolikoSatiJeRadio) PK (Radnik_ZadatakID, SessionNum)

Znaci moze i na jedan i na drugi nacin. Ajde da uporedimo:

Teorijski nacin ima jednu kolonu vise u WorkingSessions. Nacin 'iz prakse' ima jedan index vise u RadniciNaZadacima (AK, Alternate Key). Po pitanju upotrebe prostora smo dakle gotovo isti. Ti si malo bolji, jer u tabeli WorkingSessions imas 2 kolone u PK, a ja imam 3. Prostor nije skup u danasnje vreme, pa se ne bih o tome previse brinuo.

Sto se tice efikasnosti, ja znam direktno iz tabele ko je radio na kom zadatku u kom danu, a tebi treba JOIN.

Sto se tice rada, ti imas vise da radis (jedan index vise, jedan JOIN vise). Da li je to mnogo vise rada - nije. Da li tvoj Radnik_ZadatakID radi brze nego moj (Id_radnik, id_zadatak), to ne mogu da kazem zasigurno, ni da ni ne.

Eto, opet nismo odgovorili coveku - zasto bas mora Radnik_ZadatakID umesto (RadnikID, ZadatakID)? Mala usteda u prostoru? Ma kako zvucalo neprijatno, i dalje stoji ono - 'lakse se pise JOIN ako imas PK od jende kolone'

Osim ako mi ne pokazes kako bi pomocu kljuca Radnik_ZadatakID resio problem koji si postavio na efikasniji nacin nego sto sam predlozio.

----- ovde menjam temu na ovo ----------------

Ja bih pitao ovakva pitanja:
1) Neka imamo tabelu WorkingSessions (Radnik_ZadatakID, SessionNum, Datum, KolikoSatiJeRadio) , kakav god da je PK, nema veze. Ako radnik u isto vreme moze da bude rasporedjen, na nekoliko zadataka, kako obezbediti da u jednom danu nema vise od 8 sati rada? Kako spreciti ovo u tabeli:

RadnikD_ZadatakID, SessionNum, Datum, KlikoSatiJeRadio
1 1 24 Juli 2006 6
1 1 24 Juli 2006 8

Eto, covek odradio 14 sati. Kako to spreciti? Front End resenja ne dolaze u obzir.

2) Ako je tabele WorkingSessions ovkava:
WorkingSessions (Radnik_ZadatakID, SessionNum, Datum, PocetakRada, Krajrada) Pocetakrada, KrajrRada = sati u okviru dana, (ovo mu dodje kao neki timesheet)
Kako obezbediti da se u tabelu ne unose preklapajuci intervali? na primer, da se ne moze uneti:
RadnikID=1, ZadatakID=1, Datum = 24 Jul 2006, PocetakRada = 8:30 , KrajRada = 15:45
RadnikID=1, ZadatakID=2, Datum = 24 Jul 2006, PocetakRada = 10:15, KrajRada = 12:20

I ovaj krade na satima. Bio na dva zadatka u isto vreme.

Ponovo ce firma da propadne. Mora da propadne, ako peraci prozora svakog dana uzimaju i vracaju materijal i alat iz magacina. Preovodice vise vremena na cekanju u redu u magacinu i voznji do magacina i od magacina do radnog mesta, nego sto rade.

Sto se tice prostora na disku, ne opterecuje me uopste . Teorijska resenja uzimaju za nijansu vise prostora nego uvodjenje surogat kljuca. Tacno je da ako se stalno migrira kljuc u child tabele, zavrsices sa tabelam koje imaju PK sastavljen od 5-6 ili vise polja. To zaista postaje strava da se ordrzava, ali 2-3 olja, to nije nista. Da li ce nesto da bude sporo za operatera na unosu, zavisi od dizajna front enda, ne od toga kakav je PK izabran. Ja sam samo pokazao da problem moze da se resi, na oba nacina, a Grebenar je tvrdio da ne moze da se resi ako se koristi kompozitni kljuc nego mora surogat.

I nikako ne mogu da zamislim radnika koji pamti u glavi koji je njegov kljuc Radnik_Zadatak_ID, za svih pet zadataka na koje je odredjen, a sve da bi operateru bilo lakse. On zna svoje ime i da ce da radi na zgradi u Terazije Br 2 (Palata Albanija?). Valjda treba radniku da bude lakse, jer on donosi pare. Operater je tu da olaksa radniku posao, ne obrnuto.

Ako radnik radi istovremeno na vise zadataka, pa mu treba isti alat za svaki zadatak, hoce li da izuzme isti alat vise puta? Kako na ovo odgovaraju modeli koje smo predlozili? Djoka Alpinista ce danas da pere prozore na tri zgrade. Alat je isti - konopci i sundjer. I deterdzent ne mozi da duzi na parce. On zaduzi kanticu od 10 litara, jer mu za svaki posao treba 3 litra, i jedan mu ostane da vrati nazad. Onda firma zakljuci da je bolje da alpinisti-peraci prozora zaduzuju po 30 litara deterdzenta i da se u centralu vracaju jednom nedeljno, umesto svaki dan, da se ustedi na gorivu. Kako nasi modeli podrzavaju ovo, bez obzira na to koliko kolona imamo u PK?

A moze i ovaj model poslovanja: firma nema magacin uopste, pa ni magacionera. Radnici - peraci, imaju kreditne kartice na ime firme i sami kupuju materijal, koliko im treba, kad im treba. Firma povremeno pravi obracun - koliko je ko materijala potrosio. Radnici ce svakako da ukradu po neki litar sredstva za pranje prozora. Neka ih, jeftinije je to nego placati zakup za magacinski prostor, magacionera i sve sto uz to ide. Posto forma PRATI POSLOVANJE (razlicit pojam od 'vodi kjigovodstvo') onda ce lako da vidi kad neko debelo iskoci van uobicajenih granica potrosnje pa ce da preduzme nesto.

;-)

Za "način iz prakse" bolje je rešenje:

RadniciNaZadacima (Radnik_ZadatakID, RadnikID, ZadatakID,SessionNum, Datum, KolikoSatiJeRadio) onda imas PK = Radnik_ZadatakID i AK (RadnikID, ZadatakID, SessionNum)

Ovo je već velika razlika u odnosu na "teoriju", umesto dve tabele imaš samo jednu

ZA Mladju: Nije dobro, dve stvari su pomesane. Tabela RadniciZadaci kaze ko je dodeljen kom zadatku i nista vise. To ti je kao neki sastav time. Druga tabela kazuje ko je radio koliko sati - predstavlja kolicinu rada. Kolicina rada i pripadnost zadatku su dve razlicite stvari. Sta ako je neko sef, pa u stvari ne radi nista, a dodeljen je na zadatak, ili na vise zadataka? Ako ne prijevi sate, neces ga nigde videti. Ili, neko je bio bolestan, i nije se pojavio pa nemas nista u tabeli. Zato moras da imas dve tabele, RadniciZadaci i WorkSessions. Pa makar neko bio dodeljen zadatku, a ne radio nista. Sve ovo nema veze sa izborom i konstrukcijom PK.

Ako pitas 'Koji radnici su dodeljeni zadatku broj 1' resenje sa jednom tabelom te primorava da pises GROUP BY iskaz, jer neki radnici mogu da su radili vise puta. I opet mozes da promasis one koji nisu radili uopste, a dodeljeni su zadatku. Sa dve tabele, resenje je trivijalno, a ako dodas LEFT JOIN sa WorkSessions i GROUP BY, vidis ko je koliko sati radio, a neko je radio NULL sati, znaci nije radio, a trebao je.

Ako vec i ides sa jednom tabelom, lepo si primetio da ti treba AK, jer bez njega ne mozes da obezbedis jedinstvenost reda. A kad vec imas i moras da imas AK, cemu ti onda sluzi vestacki PK? I na teorijski nacin mozes da izbacis jednu tabelu ako bas insistiras:

WorkingSessions ( Id_radnik, id_zadatak, SessionNum, Datum, KolikoSatiJeRadio) PK= (Id_radnik, id_zadatak, SessionNum)
je isto sto i
RadniciNaZadacima ( Id_radnik, id_zadatak, SessionNum, Datum, KolikoSatiJeRadio) PK= (Id_radnik, id_zadatak, SessionNum)

Samo se ime promenilo. I isto je pogresno, kao sa vestackim kljucem, nema veze sa kljucem, svejedno su pomesane zabe i babe. Ako koristis jednu tabelu, kaok ces uopste da kazes 'dodeljujem radnika br 7 zadatku br 15 a radice tek od sledece nedelje'. 'Jedna tabela' zahteva da se unese SessionNum, Datum, KolikoSatiJeRadio, a to na pocetku NEMAMO. Znaci, jedna tabela ne dozvoljava ono od cega smo poceli - da se radnik dodeli zadatku. 'Jedna tabela' prihvatice unos samo kada vec postoje sati i SessionNum, a to se desava POSLE pocetka radova. Mozes da kazes 'pa ostavicu da mi ta polja budu NULL' i to ce da znaci 'radnik dodeljen zadatku'. I tu ododsmo do djavola. Kako ces da obezbedis da po svakom radniku i zadatku imas tacno po jedan red gde su SessionNum, Datum, KolikoSatiJeRadio NULL vrednosti? Ne volis NULL ? Dobro, upisaces nesto kao Session=0, KolikoSatiJeRadio = 0. Onda imas dve vrste podataka u istom polju. KolikoSatiJeRadio = 0 nije nikakva kolicina rada, to znaci da je radnik dodeljen zadatku, a KolikoSatiJeRadio = 10 je 10 sati. Eto ga na kraju - dve vrste sustinski razlicitih informacija u istoj koloni - sati i 'znacenje'. Ako me pamet ne vara, to je prekrseno 1NF pravilo. A ako nemamo ni 1NF, onda nam ne treba ralaciona baza, moze i file system. A znas zasto je ovo? Vestacki kljuc te prevario i ucinilo ti se da mozes ni manje ni vise nego da izbacis celu jednu tabelu iz modela. E zato ne valjaju vestacki kljucevi, dozvoljavaju puno toga sto inace nije logicno, pa navedu coveka na pogresdan dizajn a da toga nije ni svestan. Taman posla da ih ne treba upotrebljavati, samo treba biti veooooma oprezan. Zacas se okliznes.

Jos jednom, ja nisam pokusavao da dokazem koji je nacin 'bolji', o tome svako ima svoje misljenje i neka ostane tako. Tvrdnja je bila da teorijski nacin nesto 'ne moze', pa sam pokazao da moze.

A sto bi nesto zvali teorijski nacin, ako postoje bar neki ljudi koji ga upotrebljavaju u praksi?

Svo vreme mi se čini da nešto propuštamo. Naslov teme je teorija protiv prakse, a neko je ranije već lepo rekao da teoriju pišu praktičari. Dakle ova tema glasi praksa protiv prakse :)

Postoji formalna, matimatički jasna, teorija relacionog modela podataka, koja ima svoje aksiome, definicije, teoreme, ali NE POSTOJI FORMALNA teorija o dizajnu baza podataka.

Ako dvojici matematičara date dužinu stranice kvadrata sa zadatkom da izračunaju obim, obojica će doći do jednog jedinog ispravnog rešenja. Isto će se desiti i sa bilo kojim zadatkom iz fizike, hemije, postoji samo jedno jedino ispravno rešenje.

Ako dvojica praktičara dizajniranja baza podataka rešavaju isti problem, ne moraju doći do istog rešenja! Ne postoji jasan, zakonima popločan put za rešavanje problema. Neko je već ranije rekao da je dizajniranje baza podataka skup kompromisa! Ja bih dodao da dizajniranje baza (pa i ostalo programiranje) još uvek u sebi sadrže i dobar deo UMETNOSTI. Ta umetnost nam dozvoljava kreativnost u rešavanju zadataka.

Postoje autori koji trpaju surogatni ključ (OID) u svaku tabelu baze podataka (Scott Ambler?).
Postoje autori koji smatraju surogatne ključeve prihvatljivim (C.J. Date).
Postoje autori koji se gnušaju surogatnih ključeva (Joe Celko).

Izbor je individualan.




Ovo me navodi da relacija Radnik_Zadatak uopšte ne postoji, te da svojim prisustvom i imenom samo uvodi zabune (ja sam je cak ranije bio preimenovao u Poslovi). Sada mi deluje da je ispravno da se umesto Radnik_Zadatak (ili mog Poslovi) uvede element Radni_Nalog, i to nesto poput:

I eto ga jedan atribut kao ključ tabele koja povezuje radnike i zadatke! Ali ta tabela više nije relacija (u ERD smislu) nego je postala entitet, čija definicija glasi: Radni nalog je dokument kojim se tim radnika određuje i upućuje na realizaciju jednog posla (ugovora). Ovim radnim nalogom se vraćam na moj prvi post slučaj broj 1.



Ovo je stvar GUI-a. Ni jedan zakon ne nalaže da se za odabir Radnog_Nalog-a moraju koristiti tri ComboBox-a. Može se koristiti jedno dugme sa labelom 'Odabir radnog naloga' na čiji klik se otvara forma koja prikazuje sve nezavršene radne naloge. Pomoću dodatne forme se bira odgovarajući radni nalog.

I slažem se da su tri ComboBox-a potencijalno brža i jednostavnija za programiranje. Kažem 'potencijalno' jer i to zavisi od Application Framework-a koji se koristi.



Što se mene tiče, rezime ove teme glasi:
1. Prednosti surogat ključa:
- brže izvršavanje upita (spomenuo amladjo),
- prostiji JOIN-ovi,
- lakše (brže) povezivanje sa APF-om (jablan), i slično tome lakše (brže) programiranje GUI-a.
2. Prednosti prirodnog ključa
- manje JOIN-ova,
- jači integritet podataka.

Ako izuzmem prednosti vezane za JOIN-ove, ostaje mi da je prednost surogat ključeva u brzini i lakoći, u odnosu na integritet. Brzina se prevazilazi bržim hardware-om, a lakoća kvalitetnijim DBA i programerskim alatima. Brži hardware i kvalitetnije alate donosi budućnost. Ono što budućnost nemože da nam pruži je očuvanje integriteta podataka. Budućnost naprotiv ide na ruku razbijanju integriteta baze podataka.

Moj izbor je jasan. Ne opredeljujem se ni za teoriju ni za praksu. Opredeljujem se za jači integritet baze podataka.

Potpis

"The best code is no code at all."
- Zidar (ES član)
"Biggest obstacle to learning
SQL is unlearning procedural
programming." - Joe
Celko
"Minimize code, maximize data."
- A. Neil Pappalardo

Za Zidara: U pravu si, promakao mi je sastav tima. Ovo je nešto što bi Šef sigurno tražio

Prva varijanta:
ZADACI (ID_Zadatka,NazivZadatka,Trajanje,PotrebnoRadnoMestoID,BrojEtapa)
POSLOVI (ID_Posla,RadnikID,ZadatakID,Etapa,Dodeljen,Zapocet,Zavrsen)

Druga varijanta bi bila:
ZADACI (ID_Zadatka,NazivZadatka,Trajanje,PotrebnoRadnoMestoID,BrojEtapa)
POSLOVI (ID_Posla,RadnikID,ZadatakID,Dodeljen,Zapocet,Zavrsen)
ETAPE (ID_Etape,PosaoID,Dodeljen,Zapocet,Zavrsen)

Alati i materijali su vezani za ID_Posla što mi zabranjuje mogućnost korišćenja alata i materijala po etapama sa druge strane mogu da formiram tim pa etape rešavam u sklopu jednog posla istim alatom i materijalom. Ovo mora da je bitna odluka pri izmeni baze.


Nema razloga da je ovo vezano za izbor ključa, više je stvar odluke šta se želi postići sa etapom. Druga varijanta bolje oslikava našeg alpinistu, nije razdužio alat i materijal već samo "napravio pauzu", prva varijanta je više prilagođena izradi nameštaja: isti je radnik i zadatak a koriste se različiti alati i materijali.


Dugi je put, čini mi se, mnogih relacija koje su postale entitet. Dobar primer je tabela Radnik_Zadatak koja je postala Radni_Nalog. Jedino što sa sigurnošću možemo da tvrdimo jeste da ne znamo kada će se ta transformacija desiti u konkretnom IS-u, možemo samo da se nadamo da previše krut integritet baze neće ostaviti našu bazu daleko iza konkurencije.

za Zidara
odgovarajući na moj komentar si između redova odgovorio na postavljeno pitanje. Ja sam mislio da je to bilo jasno iz mojih postova: praksa je prepoznala da je relacija radnik-zadatak najcesce entitet, nazvao ga kako god workingSession, aktivnost, parce_doprinosa. (ovo je chachka rezimirao) Kada ubacis vremensku komponentu obicnim filterom dobivas sastav tima u svakom pojedinom momentu. Dakle, poenta je u tome da je ID_Session dio jedne strukture kojom su definisani i razgranati poslovi i da mu se (putem FK) pridruzuju koji zadatak (čak više njih - u smislu aktivnosti) i koji radnik, i naravno (atributima) kada i koliko. Nadalje su tu pridruzivanje materijala, alata i ev. nekih dodatnih veza ka ostatku sistema.
Ja nisam tvrdio da se moj primjer ne moze rijesiti kompozitnim kljucevima vec da u jednoj tabeli sa kljucem radnikID, zadatakID to ne može pokriti. (tvoje riješenje uvodi novu tabelu što je OK).

Zapravo uopšte ne razmatram koju težinu to donosi na iplementaciju baze, već u najranijoj fazi projekta želim postaviti skup entiteta čije životne cikluse želim pratiti - pri tome nastojim da moj model bude što manji a da je dobra platforma za daljnji razvoj. Iako najčešće sam pišem upite (a u eri query buildera) gotovo mi je nevažno koliko je "dugačak join". Malo mi je bitno i da li ću imati koji index više - sve dok dobivam optimalne planove za izvršavanje upita koji realizuju projektni zadatak.

Moram naglasiti slijedeće: uvođenje objektnih ID (OID - u prethodnom postu sam objasnio da to NISU ni surogat NITI vještački ključevi) kao alternativu kompozitnim ključevima, treba da je konsekventno. Recimo da ih smatramo internim imenima u BP. Dobar dio posla tada otpada na održavanje njihove unikatnosti, integriteta i povezivanja sa alternativnim / prirodnim ključevima. To je u startu minus. Šta dobivamo - vjerniju sliku tj. veću podudarnost modela sa dijelom stvarnog okruženja i gotovo uvijek vec pripremljeni odgovor na dodatne upite i zahtjeve - jer već na nivou modela govrimo o konkretnim stvarima nečekajući da doplivamo do neke relacije - npr. alat može biti u alatnici, kod radnika ili na popravci - ako je kod nas ili može biti tek naručen.



Praksa MRP i planiranja/praćenja proizvodnje ima "tri Baze Podataka" u jednoj: plansku, aktivnu i rezime. To bitno usložnjava sistem, ali je moguća aproksimacija (koje ce prije ili kasnije tražiti kruha tj. korektniju nadgradnju) da se putem atributa status ta složenost unekoliko prevaziđe.
Što se tiče "kako sprečiti ovo ili ono" to spada u biznis pravila. Dobar dio njih se rješava na serveru (Client/Server) ili danas sve ćešče u okviru poslovnog sloja kod n-tier sistema (radi izdvajanja poslovnih pravila su i uvedeni). Slažem se se da su takve kontrole na front-endu na labavim nogama. Recimo da je rješenje da SP insertuje ili mjenja slog nakon što izvrši određene provjere.

Dilema je mnogo i resenja ima beskonacno mnogo. Kao sto rece Chachka, jedan deo ovog posla je umetnost. Ta umetnicka komponenta nam omogucuje da za date uslove u datom okruzenju napravimo bazu koja pokriva uglavnom sta se trazi, a fleksibilna je dovoljno da se moze nadgradjivati i dogradjivati.

Ono sto mi je drago i sto postujem veoma je da je svako od nas u svom postu bar jednom upotrebio recenicu tipa 'slazem se .sa kolegom' iako naoko raspravljamo o pristupima koji su razlicitii kao pokusavamo da dokazemo da je pristup A bolji od B. Zadovoljstvo je biti u takvoj raspravi, ili bolje, razmeni misljenja. Svaka cast i uzdravlje.

Imam edno pitanje koje me poduzr muci jer ne nalazim zadovoljavajuci odgovor. U situacijo ovakvoj:

Ocigledno je BrojEtapa odredjuje kardinalnost veze izmedju Zadaci i Poslovi. Kolona Poslovi.Etapa moze bit u opsegu 1,2,3...N, gde je N=BrojEtapa. Pri tome je moguce da je BrojEtapa fiksa n = u tabeli POslovi MORA biti tacno toliko Etapa nakraju, ili je tio samo maksimum = u tabeli Poslovi moze biti maksimalno N Etapa. Pitanje je: kako obezbediti da se ovi zahtevi ispostuju?

Ja ima neka resenja kojima nisam 100% zadovoljan ali ne umem bolje.
- Ako je BrojEtapa fiksan i obavezan, onda naopisem trigger u Zadaci, On INSERT, koji procita BrojEtapa i odmah ubaci u tabelu Poslovi toliko redova. Sve osim PK postaje NULL, pa se kasnije popunjava. Na Poslovi imama tada trigger koji sprecava brisanje i dodavanje.
- Ako je BrojEtapa samo dozvoljeni maksimum = Poslovi mogu da imaju manje ili jednako redova od Zadaci.BrojEtapa, onda nema triggera na Zadaci. Postoji samo trigger na Poslovi koji na INSERT proverava da li vec imamo dozvoljen broj etapa.
Ima li neko nesto sto je jednostavnije za upotrebu od triggera? (front end resenja ne prihvatamo

Drugo pitanje je kako na nivou CHECK constrainys ili nesto tako spreciti preklapanje etapa?. Drugim recima, svka etapa moze da pocne samo posto je prethodna etapa zavrsena. Nesto kao:
NoviRed.POSLOVI.Zapocet <= (SELECT MAX(POSLOVI.Zavrsen) WHERE ID_Posla< NoviRed.ID_Posla)
MS SQL ne dozvoljava SELECT u CHECK constraint, barem do verzije 2000. Da li neki drugi sistem dozvoljava ovakve stvari? SQL standard predvidja da se u CHECK CONSTRAINT mogu koristiti SELECT izkazi ali ne znam da li je to negde stavrno uradjeno.

Da li si čitao knjigu od Richard T. Snodgrass - Developing Time-Oriented Database Applications in SQL? Besplatno se može skinuti u PDF formatu sa njegovog sajta u odeljku Recent Books.


InterBase dozvoljava upotrebu SELECT-a u okviru CHECK CONSTRAINT-a. Na primer:

CHECK CONSTRAINT ch_tmp_samo_pet_redova dozvoljava da tabela Temp ima maksimalno 5 redova.

Potpis

"The best code is no code at all."
- Zidar (ES član)
"Biggest obstacle to learning
SQL is unlearning procedural
programming." - Joe
Celko
"Minimize code, maximize data."
- A. Neil Pappalardo