i mintabell är uid bigint, not null och PK.
Det som jag faktiskt tror ställer till det är att min enherrejössessubfråga är en rätt saftigt select och att FK så att säga "försvinner" på vägen. Men innehållet i enherrejössessubfråga har alltid en och endast en referens till mintabell. Sedan vid en inner join så ska de poster i enherrejössessubfråga som inte har min i mintabell tas bort, det är denna kontroll som ställer till det. I left outer join tas alla med, utan omsvep.
Men det gör inget, eftersom det alltid existerar exakt en rad i mintabell som matchar
Ska sägas att det är några år sedan frågan skrevs, men fenomenet är intressant.
När jag pluggade databaser för dryga 20 år sedan så hade kursledaren en förkärlek till tre nyckeltyper:
PK, FK och CK. Den senare, kandidatnyckeln är bekvämt att använda många gånger.
Han körde även med mängdlära, vilket fick mig att minnas matten i första klass och boken "Hej Matematik".
"Ringa in en mängd bananer. Ringa in en delmängd bananer som är inom delmängden apor och bananer."
Tur att jag var för gammal för Vilse i pannkakan...
Många designar ofta ett artikelregister med artikelnummer som PK, eller fakturor med fakturanummer.
Det som skiljer är att CK INTE ingår i relationen, tex:
- Kod: Markera allt
artnr char(20), unique, PK
vs
uid bigint, unique, isIdentity, PK
artnr char(20), unique (CK)
I den senare så lever uid "sitt eget liv", utan att jag behöver bry mig.
Sedan går det snabbare att jämföra bigint:ar mot att jämföra strängar.
Jag har även uid som benämning på PK i ALLA tabeller. Detta för att inte bli förvirrad!
Kolumnen som är FK heter alltid <refererar till>Id, tex i fakturaraderna, FakturaId bigint FK.
Men nu är det bara att kämpa vidare, veckans sista skälvande minuter!