[es] - uvijetni FK?.. .

Srodne teme

Kliknite za generisanje liste srodnih tema...

Navigacija

Brisanje liste

Lista poslednjih: 16, 32, 64, 128 poruka.

Impaler

Član broj: 89808
Poruke: 183

+33 Profil

uvijetni FK?.. .

^{03.04.2008. u 08:09 - pre 195 meseci}

imam recimo tablicu u kojoj su neki stupci medjusobno iskljucivi, znaci ako je zapisan podatak u jednom polju onda nesmije biti u drugom i sl.

i pitanje je kako to rijesit? jel moguce recimo to rijesit kao 2 stupca jedan koji se zove TIP a drugi FK i onda ako je TIP recimo tip1 onda je FK referenca na tablicu tipa1, a ako je TIP = tip2 onda je FK referenca na tablicu tipa2.

NO FATE

Odgovor na temu

Koce
DBA
Serbia, Belgrade

Član broj: 59217
Poruke: 144
*.vektor.net.

+1 Profil

Re: uvijetni FK?.. .

^{03.04.2008. u 08:49 - pre 195 meseci}

probao si sa constraint?

Odgovor na temu

Impaler

Član broj: 89808
Poruke: 183

+33 Profil

Re: uvijetni FK?.. .

^{03.04.2008. u 13:47 - pre 195 meseci}

ne.
imam sad drugi problem mozda niije direktno vezan za ovaj:
- ako imam takav slucaj sa iskljucivim poljima (koja mogu biti reference); onda nemogu kreirati view (u bazi sql server) u slucaju ako je referenca NULL zato jer nije dozvoljeno primary key postavit za nul, i view ce vratit samo one recorde koji imaju referencu koja nije NULL.

pa moram onda "budžit" nesto i nemogu report napravit u visual studiu onako samo klikanjem. hito bi napravit da mi za ta polja u reportu bude prazno, ako je null. (za pocetak)

NO FATE

Odgovor na temu

Zidar
Canada

Član broj: 15387
Poruke: 3085
*.100.46-69.q9.net.

+79 Profil

Re: uvijetni FK?.. .

^{03.04.2008. u 13:53 - pre 195 meseci}

Mirise na problem u dizajnu. Ako su dve kolone iskljucive (Ako [A] onda NE [B]), tu naryusavas neko pravilo normalizacije koje kaze 'svaka kolona sme da zavisi samo i samo od PK'. Ako donormalizujes shemu tvoje baze podataka, mozda sadasnji problemi nestanu sami od sebe. "budžit" nije bas dobar metod. Ako nam das vise informacija mozda ti mozemo pomoci, sa normalizacijom ili sa upotrebom constraints i FK.

:-)

Odgovor na temu

Impaler

Član broj: 89808
Poruke: 183

+33 Profil

Re: uvijetni FK?.. .

^{03.04.2008. u 14:19 - pre 195 meseci}

imam u zapisniku definirano opcionalna polja:

Code:

Razvođenje
--------------
Datum|Oznaka
|

polje oznaka prema pravilniku moze bit neka od 4 vrste podataka:
- string
- datum
- naziv i adresa
- broj Organizacijske jedinice

NO FATE

Odgovor na temu

Zidar
Canada

Član broj: 15387
Poruke: 3085
*.100.46-69.q9.net.

+79 Profil

Re: uvijetni FK?.. .

^{04.04.2008. u 14:49 - pre 195 meseci}

Losa je ideja da se u jednu kolonu trpaju raznorodni podaci. Na papirnom obrascu, moguce je ustu kolonu upisati nekad datum, nekad adresu a nekad radnu jedinicu, a nekad bilo sta. Covek kad pogleda, zna sta je sta. Medjutim, kompjuter nije toliko pametan. Sam si se uverio da ne ide da trpas razlicite podatke u jedno isto polje. Imas nekoliko opcija, od kojih su neke bolje neke losije. Ne mozemo da kazemo sta je bolje, jer ne poznajemo situaciju. Ovo su ti opcije:

1. uvedes 4 kolone
- string - sta ti je ovaj string? bilo koji tekst? Komentar?
- datum
- naziv i adresa
- broj Organizacijske jedinice
Onda uopises sta ti treba gde treba. Ovo generalno nije dobra opcija, jer:
- ce neka polja ostati prazna (NULL) i nikad ne znas da li su prazna zato sto treba da budu prazna ili zato sto smo zaboravili podatke, ili ih nemamo. Jos gore je kad podaci postanu dostupni kasnije.
- moze se desiti da je dozvoljeno da samo jedno od ovih polja bude popunjeno, a ostala da su NULL. Treba ti CONSTRAINT koji dozvoljava samo jedno polje da je popunjeno. Moze da se napise, ako treba. Ovo je bolja situacija nego kad polja mogu biti proizvoljno popunjena.

Resenje 2: Uvedes dodatnu tabelu, Oznaka pa imas

GlavnaTabela (ID, datum)
Razvodjenje (ID, VrsatRazvodjenja, Razvodjenje, DatumRazvodjenja) gde se ID koristi u FK

Ovo je malo bolje nego 4 kolone u istoj tabeli. Unosis sta imas, kad imas. Ovako .Ovako bi zgledalo:

Code:

GlavnaTabela:
ID        Datum
------------
1,    '20080101'

Razvodjenje:
ID, VrsatRazvodjenja, Razvodjenje,                                 DatumRazvodjenja
--------------------------------------------------------------------------
1,  'Naziv i Adresa',     'Narodnih heroja 115, Beograd, srbija', '20080101'
1, Broj Org. Jedinice', 115,                                              '20080101'

Problem sa ovim je sto u koloni Razvodjenje imas podatke razlicitog tipa, datumske, numericke i tekstualne. To stvara probleme pri validaciji. Naravno, lako je reci 'neka paze sta unose'. Medjutim, tako ne rade profesionalci. Profesionalci moraju da stite integritet podataka i od samog korisnika.

Reasnje 3:
Za svaki tip razvodjenja (ima ih tacno 4) uvedes po jednu tabelu, slicno kao u (2). Ovog puta nema mesanja tipova podataka i lako se uspostavljaju CONSTRAINTS.

IMa jos varijanti, ove tri su mi pala na pamet. Dalja analiza je nemoguca bez poznavanja biznis procesa koji se pokusava podrzati modelom baze podatka.

Malo sam pod utiskom da je sitem dizajniran doslovnim preslikavanjem papirnog obrasca. To e moze raditi u Excelu, ali ne i u SQL bazi podataka.

Odgovor na temu

Impaler

Član broj: 89808
Poruke: 183

+33 Profil

Re: uvijetni FK?.. .

^{04.04.2008. u 17:32 - pre 195 meseci}

yep, najvjerojatnije ce na kraju biti varijanta 3 . no to ce sacekati do ponedjeljka.

Citat:

Malo sam pod utiskom da je sitem dizajniran doslovnim preslikavanjem papirnog obrasca. To e moze raditi u Excelu, ali ne i u SQL bazi podataka.

heh, mozda si u pravu , al josh je to u fazi inicijalizacije i planiranja tako da nije zabetonirano.

NO FATE

Odgovor na temu

zmau
Dragan Jovanović
programer
Šabac

Član broj: 80834
Poruke: 290
89.216.89.*

+80 Profil

Re: uvijetni FK?.. .

^{05.04.2008. u 15:59 - pre 195 meseci}

Citat:

Nekada ovakav dizajn ima dosta smisla i prirodno prati logiku realnog sistema. Odnosno, nekada su 2 zapisa iz baze suštinski istog tipa, osim što se jedan odnosi na babe a drugi na žabe. Klasičan primer : dokument u poslovanju predstavlja transfer robe iz jednog poslovnog entiteta u drugi. Jedan od tih entiteta je obavezno magacin (radna jedinica) unutar firme, a drugi može biti isto magacin (kod internih dokumenata), a može da bude i poslovni partner (kod externih). Odnosno, nekad će postojati jedna referenca na tabelu magacin i jedna na tabelu partner, a nekad i 2 reference na tabelu magacin. A svi ti zapisi suštinski predstavljaju promet, i logično je da budu unutar iste tabele, inače ćeš morati da ih union-išeš prilikom bilo kog kreiranja izveštaja. A to je dosta neudobnije.
A taj gep koji nastaje između teorije relacionog modela baza podataka i praktičnog problema može sasvim logično, udobno i bezbedno da se prevaziđe unutar aplikacije

Citat:

Covek kad pogleda, zna sta je sta. Medjutim, kompjuter nije toliko pametan.

Naravno da jeste. Nije u pitanju nikakvo kreativno razmišljanje, nego egzaktna logika koja se da isprogramirati. Naravno, u okviru konkretnog sistema se postavlja pitanje koliko logike treba držati u bazi, a koliko u aplikaciji.

Citat:

Naravno, lako je reci 'neka paze sta unose'. Medjutim, tako ne rade profesionalci. Profesionalci moraju da stite integritet podataka i od samog korisnika.

Srećom, pa između baze i korisnika obično postoji još jedan sloj - aplikacija. I, nevezano za logiku implementiranu u strukturi baze, ozbiljan informatičar će validaciju ulaznih podataka ugraditi i u samu aplikaciju, tako da korisnik odmah dobije fidbek o validnosti ulaza. I onda, kad imaš korektno odrađenu (i održavanu!) aplikaciju, poneki 'propust' na bazi ne mora da bude problematičan. Makar u situacijama kada tačno znaš (i znaš da ćeš i dalje znati) koje sve aplikacije pristupaju bazi, a to je dosta česta situacija. I moje dosadašnje iskustvo govori baš to.

Ne tvrdim da ne treba držati što više logike u bazi. Samo kažem da to nije jedina bitna stvar i da treba balansirati. Nekada preterano komplikovanje strukture baze podataka može dodatno da zakomplikuje izradu aplikacije koja radi nad tom bazom, i da ta dodatna komplikacije može da uzme programeru više energije nego što bi mu uzelo integrisanje te logike u aplikaciju.

it works on my machine

Odgovor na temu

Zidar
Canada

Član broj: 15387
Poruke: 3085
*.100.46-69.q9.net.

+79 Profil

Re: uvijetni FK?.. .

^{07.04.2008. u 15:03 - pre 195 meseci}

Slazem se da se naravno sve moze isprogramirati. I naravno kad god dizajn baze zahteva nesto jace od trivijalnog, treba pribeci programiranju. Ako se stim slozimo, pitanje je postavljeno na pogresnom forumu. Ovo je forum za baze podataka i nekeo je prirodno da tezimo da bar na ovom forumu resimo probleme u domenu dizajna baza. Ako je to tesko, pa odustanemo, onda temou treba preseliti na forum programiranje. Sve se moze isprogramirati, samo treba imati dovoljno memorije

Odgovor na temu