[ M E N E @ 14.01.2008. 10:30 ] @
Voleo bih da me neko ispravi...

kad imam dve tabele sa tri jednaka polja po kojima vrsim povezivanje (nisu strani kljucevi!)
a svako od ta tri polja moze poneti vrednost null (i tu postoji zavisnost, jer je u pitanju hijerarhijsko uredjenje: ako su ta tri polja A, B, C, onda ako je A != NULL, B moze biti NULL, a ne mora, a ako je B!=NULL, C moze biti a ne mora NULL, medjutim, kad je A!=null i B i C moraju biti null, tako i za B i C....)

join (bilo koje vrste) nece proci na "ON 1.A=2.A AND 1.B=2.B AND 1.C=2.C"

jer ce ovo uzeti u obzir samo kada nisu NULL vrednosti, tacnije NULL nije jednako drugom NULL.

sada moj join mora imati varijante:
1. kad su svi jednaki, sto sam gore napisao
2. kad su jednaki po A, a B i C su NULL (sto moram proveriti na obe strane)
3. kad su jednaki po A i B, a C je NULL (sto moram proveriti na obe strane)
4. kad su sva tri jednaka NULL (sto, takodje, moram proveriti na obe strane)

(moze li jednostavnije?)
[ DarkMan @ 14.01.2008. 13:40 ] @
Da li bi pomoglo da koristis ISNULL?
Code:

ON ISNULL(1.A,0)=ISNULL(2.A,0) AND ISNULL(1.B,0)=ISNULL(2.B,0) AND ISNULL(1.C,0)=ISNULL(2.C,0)
[ Zidar @ 14.01.2008. 15:20 ] @
Izgleda da imas relaciju:
A (is parent of) B
B (is parent of) C

gde se dozvoljava da roditelj nema dete. I imas tacno tri nivoa, A,B,C

Nije li ti lakse da reorganizujes tabelu ovako:

MemberID ParentID MemberLevel
1 1 A
2 1 B
3 2 C
4 4 A
5 5 B
6 6 A


Oni na nivou A su uvek sami sebi roditelj. (Ovo moze i na druge nacine, da pokazes da je neko na vrhu hijerarhije)

Ako za datog roditelja postoji nivo B, onda postoji i red u tabeli gde je ParentID = ParentID od posmatranog A. Ako posmatrani A neme svog B, onda nema ni reda u tabeli.

U datoj tabeli, onaj ciji je MeberID = 1 ima sina B (ID = 2) i unuka C (ID=3)
Member 4 ima samo sina B (ID = 5), koji nema svog sina.
member 6 nema sina, pa nema ni unuka.

Posto ima stacno tri nivoa, lako je videti hijerarhiju u SELECT iskazima sa fiksnim JOIN, a mozes upotrebiti i CTE.

Ako imas NULL vrednosti koje ti stvaraju probleme ove vrste, onda verovatno nesto nije u redu sa dizajnom tebele. Bese neko pravilo normalizacije koje kaze da atributi smeju da zavise samo od PK, a ne i jedan od drugoga. Tacno, NULL vrednosti stvaraju ali i ukazuju na probleme u bazi.

[ M E N E @ 15.01.2008. 08:36 ] @
@DarkMan
Hvala na predlogu. Jedina mana je, sto, za razliku od onog nezgrapnog joina sto sam ga gore napisao, ne vrsi proveru da li se moze desiti A!=NULL, B=NULL, C!=NULL, tj. da je sloj koji ima "podsloj" jednak NULL vrednosti.
U svakom slucaju dobro resenje
@Zidar
Slazem se sa postom.
Recimo ovako: dizajn baze je gotova stvar, moje ucesce u dizajnu je bilo tehnicke prirode (sad se ja ovde opravdavam), a najveci deo posla koji ja odradjujem je, u stvari, kucanje sprocova.
Mislim da bi pretposlednji red trebalo da glasi
5 4 B
ako se ne varam?


No, napisao sam join, sve to sada radi kako treba, ali sam u ovom, vise retorickom postu, primetio jos jedan (od, verujem, mnogo) od razloga za izbegavanje NULLa. Iskreno, nisam se sreo ranije sa tim problemom "da li je NULL=NULL?", pa sam malo guglao, i naleteo na filosofske rasprave na temu :-)
Zakljucak je: NULL i NULL ne mogu da se porede (jer su vrednosti nedefinisane), pa je, otud, rezultat tog upita FALSE, a ne TRUE, kao sto sam, mlad i naivan, ocekivao
:-)
[ chachka @ 15.01.2008. 11:26 ] @
Poređenje NULL sa NULL poput NULL = NULL ili NULL != NULL za rezultat daje NULL.