---

hejsa
skal have 3 kolonner (en fra hver af 3 tabeller) til at blive
kombineret i en kolonne
fra dette:
t1.col t2.col t3.col
---- ---- ----
a1 b1 c1
a2 b2 c2
a3 b3 c3
a4 b4 c4
a.. b... c...


vil jeg gerne have:

col
----
a1
b1
c1
a2
b2
c2
....

bemærk dog at hvis f.eks. a1 og c3 var samme værdi så skal værdien kun
være i listen en gang.

kan det lade sig gøre? (MSSQL)

---

Kim Schulz skrev:

> skal have 3 kolonner (en fra hver af 3 tabeller) til at blive
> kombineret i en kolonne
> fra dette:
> t1.col t2.col t3.col


Du skal bruge en UNION-forespørgsel:

   SELECT col FROM t1
   UNION
   SELECT col FROM t2
   UNION
   SELECT col FROM t3

Dubletter bliver automatisk frasorteret (det kan undgås med
UNION ALL).

Lidt ekstra info:
- Første select bestemmer kolonnenavnene.
- Kolonnetyperne skal matche i alle medvirkende selects (de skal
kunne sættes sammen uden et cast).
- Det er muligt at sortere ved at angiver ORDER BY efter sidste
select.

> kan det lade sig gøre? (MSSQL)

Se evt. UNION i onlinehjælpen (BOL).
--
Jens Gyldenkærne Clausen
Svar venligst under det du citerer, og citer kun det der er
nødvendigt for at forstå dit svar i sammenhængen. Se hvorfor og
hvordan på http://usenet.dk/netikette/citatteknik.html

---

Kim Schulz skrev:

> Da data rækkefølge og indhold er meget random er der ikke
> umiddelbart noget man kan ordne efter. De er ordnet internt i
> hver tabel

Nej - hvis der ikke er et felt de er ordnet efter (fx et id-felt),
kan du netop ikke regne med at de ligger i en bestemt orden. Hvis
du vil have data i en bestemt orden, skal du angive den med ORDER
BY.

> Desuden så vil det du beskriver give noget ala

> a1
> a2

Nej - det kan du ikke regne med. Data returneres i den orden
sqlserveren finder dem - og det er ikke nødvendigvis alle poster i
tabel 1 efterfulgt af alle poster i tabel 2 (en test på mit system
antyder at det måske er alle poster i den sidste tabel først, og
derefter baglæns i UNION-rækken -men jeg vil ikke løbe an på at det
holder).

Hvis du vil lave en tabelvis sortering, kan du tilføje en konstant
for hver tabel:


   SELECT col, 1 as tsort FROM t1
   UNION
   SELECT col, 2 FROM t2
   UNION
   SELECT col, 3 FROM t3
   ORDER BY tsort, col


NB: Du må gerne klippe lidt i dine citater. Læs evt. min signatur.
--
Jens Gyldenkærne Clausen
Svar venligst under det du citerer, og citer kun det der er
nødvendigt for at forstå dit svar i sammenhængen. Se hvorfor og
hvordan på http://usenet.dk/netikette/citatteknik.html

---

"Jens Gyldenkærne Clausen" <jens@gyros.invalid> wrote in message
news:Xns97109FD697A2Cjcdmfdk@gyrosmod.dtext.news.tele.dk...
> Hvis du vil lave en tabelvis sortering, kan du tilføje en konstant
> for hver tabel:
>
>
> SELECT col, 1 as tsort FROM t1
> UNION
> SELECT col, 2 FROM t2
> UNION
> SELECT col, 3 FROM t3
> ORDER BY tsort, col

Så får du jo netop alle rækker fra t1 efterfulgt af alle fra t2 efterfulgt
af alle fra t3.
Var det meningen ikke at data fra de tre tabeller skulle "flettes" sammen?
Altså så tabellen kommer til at se ud som følger:

col
----
a1
b1
c1
a2
b2
c2
....
an
bn
cn

Mvh
/Per

---

Per Jensen skrev:

> Var det meningen ikke at data fra de tre tabeller skulle
> "flettes" sammen? Altså så tabellen kommer til at se ud som
> følger:
>
> col
> ----
> a1
> b1
> c1

Den form for "fletning" forudsætter så vidt jeg kan se at der er en
sammenhæng mellem 1'ere, 2'ere etc. i tabellerne. Hvis der er det,
kan man bruge et join til at lægge dem i samme post:

a1 b1 c1
a2 b2 c2
....


Rækkefølgen af poster i en selectsætning er efter hvad jeg har lært
ikke ordnet medmindre man selv beder databasen om at ordne den (med
ORDER BY). Man kan ikke lave et kriterium der hedder "første post
fra tabel1 efterfulgt af første post fra tabel2 efterfulgt af
første post fra tabel3..." som en ORDER BY-sætning.
--
Jens Gyldenkærne Clausen
Svar venligst under det du citerer, og citer kun det der er
nødvendigt for at forstå dit svar i sammenhængen. Se hvorfor og
hvordan på http://usenet.dk/netikette/citatteknik.html

---

"Jens Gyldenkærne Clausen" <jens@gyros.invalid> wrote in message
news:Xns9710A7244821Bjcdmfdk@gyrosmod.dtext.news.tele.dk...
> Rækkefølgen af poster i en selectsætning er efter hvad jeg har lært
> ikke ordnet medmindre man selv beder databasen om at ordne den (med
> ORDER BY). Man kan ikke lave et kriterium der hedder "første post
> fra tabel1 efterfulgt af første post fra tabel2 efterfulgt af
> første post fra tabel3..." som en ORDER BY-sætning.

Jamen, jeg vil da give dig så ganske ret. Men i det tilfælde hvor man ikke
angiver en ORDER BY del vil jeg dog umiddelbart tro at ordningen i den
resulterende tabel svarer til den man har angivet i primærnøglen, så
databasen kan læse sine data sekventielt ud fra det implicitte index
primærnøglen skaber.

I det tilfælde hvor så vil have rækkerne ud i deres "naturlige" rækkefølge
som Kim beder om vil jeg umiddelbart mene at man kan angive primærnøglen i
sin ORDER BY del.

Mvh
/Per

---

Per Jensen wrote:
> "Jens Gyldenkærne Clausen" <jens@gyros.invalid> wrote in message
> news:Xns9710A7244821Bjcdmfdk@gyrosmod.dtext.news.tele.dk...
>
>>Rækkefølgen af poster i en selectsætning er efter hvad jeg har lært
>>ikke ordnet medmindre man selv beder databasen om at ordne den (med
>>ORDER BY). Man kan ikke lave et kriterium der hedder "første post
>>fra tabel1 efterfulgt af første post fra tabel2 efterfulgt af
>>første post fra tabel3..." som en ORDER BY-sætning.
>
> Jamen, jeg vil da give dig så ganske ret. Men i det tilfælde hvor man ikke
> angiver en ORDER BY del vil jeg dog umiddelbart tro at ordningen i den
> resulterende tabel svarer til den man har angivet i primærnøglen, så
> databasen kan læse sine data sekventielt ud fra det implicitte index
> primærnøglen skaber.

Det kan man ikke regne med. Det vil være implementationsspefikt og kan i
princippet ændre sig fra version til version på det enkelte produkt.

> I det tilfælde hvor så vil have rækkerne ud i deres "naturlige" rækkefølge
> som Kim beder om vil jeg umiddelbart mene at man kan angive primærnøglen i
> sin ORDER BY del.

Det er noget skidt, da primærnøglen som sådan ikke bør bære den type
information. Hvis der er behov for at sortere i en bestemt rækkefølge,
skal man kunne gøre det på et af felterne, som ikke optræder som nøgle.

Mvh. Michael.
--
Visit my home page at http://michael.zedeler.dk/
Get my vcard at http://michael.zedeler.dk/vcard.vcf

---

"Michael Zedeler" <michael@zedeler.dk> wrote in message
news:CSJef.423$Cl2.4008@news000.worldonline.dk...
>
> Det kan man ikke regne med. Det vil være implementationsspefikt og kan i
> princippet ændre sig fra version til version på det enkelte produkt.

Det vil jeg nu heller ikke mene at have hævdet. Pointen var (omend den måske
ikke fremgik klart) at man blot kan angive den "naturlige" ordning man
ønsker at have (eller regner med at få når man undlader at angive den).

> Det er noget skidt, da primærnøglen som sådan ikke bør bære den type
> information. Hvis der er behov for at sortere i en bestemt rækkefølge,
> skal man kunne gøre det på et af felterne, som ikke optræder som nøgle.

Hvilken type information taler du om her?
Jeg går ud fra at primærnøglen som udgangspunkt _også_ bliver benyttet til
at indeksere tuplerne i den underliggende indeksstruktur man (databasen)
måtte benytte.
Hvorfor udelukker du primærnøglen som en mulig kandidat til sortering - og
dermed kun tillade sortering på de yderligere attributter tabellen har?

Mvh
/Per

---

Per Jensen wrote:
> "Michael Zedeler" <michael@zedeler.dk> wrote in message
> news:CSJef.423$Cl2.4008@news000.worldonline.dk...
>
>>Det kan man ikke regne med. Det vil være implementationsspefikt og kan i
>>princippet ændre sig fra version til version på det enkelte produkt.
>
> Det vil jeg nu heller ikke mene at have hævdet. Pointen var (omend den måske
> ikke fremgik klart) at man blot kan angive den "naturlige" ordning man
> ønsker at have (eller regner med at få når man undlader at angive den).

Der er ingen prædefineret naturlig ordning af forespørgsler uden ORDER
BY. Ved at bruge ORDER BY, får man forespørgsler, der performer
væsentligt dårligere, end uden.

>>Det er noget skidt, da primærnøglen som sådan ikke bør bære den type
>>information. Hvis der er behov for at sortere i en bestemt rækkefølge,
>>skal man kunne gøre det på et af felterne, som ikke optræder som nøgle.
>
> Hvilken type information taler du om her?

Information der kan bruges til andet end at referere til andre tupler.

> Jeg går ud fra at primærnøglen som udgangspunkt _også_ bliver benyttet til
> at indeksere tuplerne i den underliggende indeksstruktur man (databasen)
> måtte benytte.
> Hvorfor udelukker du primærnøglen som en mulig kandidat til sortering - og
> dermed kun tillade sortering på de yderligere attributter tabellen har?

Fordi den ordning, man får ved at sortere efter primærnøglerne ikke bør
kunne brugees til noget. Et hvert program, der reelt bruger sortering
efter nøgler, er bygget på en eller anden form for dårligt design.

Det svarer lidt til at begynde at sortere efter pointere i c.

Det skal lige indskydes at jeg tager udgangspunkt i eksemplet, hvor der
bruges blinde nøgler der (som nævnt ovenfor) kun bruges til at referere
til andre tupler. Hvis man f. eks. bruger et personnavn som primærnøgle,
kan man selvfølgelig godt sortere efter den. Den type situationer
udtaler jeg mig ikke om.

Der er en enkelt undtagelse, og det er hvis man har et program, som på
en eller anden måde har brug for at foretage et join eller på anden måde
benytte primærnøgleværdierne internt - f. eks. ift. data trukket ud
fra andre tabeller. Principielt set har man jo ikke den slags
situationer, men et er teori og andet er praksis.

Det jeg advokerer imod, er at lave programmer, som f. eks. er afhængige
af at primærnøglernes værdier oprettes i en bestemt rækkefølge, som man
så bruger efterfølgende.

Mvh. Michael.
--
Visit my home page at http://michael.zedeler.dk/
Get my vcard at http://michael.zedeler.dk/vcard.vcf

---

"Michael Zedeler" <michael@zedeler.dk> wrote in message
news:%ANef.444$Cl2.4017@news000.worldonline.dk...
>
> Der er ingen prædefineret naturlig ordning af forespørgsler uden ORDER
> BY. Ved at bruge ORDER BY, får man forespørgsler, der performer
> væsentligt dårligere, end uden.

Nej, det er rigtigt. I SQL er der ingen prædefineret ordning - det bruger
man jo netop ORDER BY til. Men vi kan vel godt blive enige om er der findes
en ordning når databasen skal evaluere en SQL-forespørgsel uden en ORDER BY
del i. Derfor _formodede_ jeg at den ville benytte primærnøglen eftersom jeg
_formodede_ og stadigvæk _formoder_ at den indekserer sine data efter i den
underliggende indeksstruktur. Jeg formoder dette da jeg dårligt kan
forestille mig bedre performance end at databasen læser sine data
sekventielt fra den underliggende indeksstruktur.

> >>Det er noget skidt, da primærnøglen som sådan ikke bør bære den type
> >>information. Hvis der er behov for at sortere i en bestemt rækkefølge,
> >>skal man kunne gøre det på et af felterne, som ikke optræder som nøgle.
> >
> > Hvilken type information taler du om her?
>
> Information der kan bruges til andet end at referere til andre tupler.

Hvordan definerer du en primærnøgle? Jeg definerer en primærnøgle som en
samling af attributter (evt. kun en enkelt) der entydigt identificerer en
hel tuple i en relation/tabel. Efter den definition bruges primærnøglen ikke
til at referere til andre tupler - andre tupler i _andre_ tabeller kan
derimod referere til tuplerne i vores tabel vha. primærnøglen. Det er ikke
det samme.

> > Hvorfor udelukker du primærnøglen som en mulig kandidat til sortering -
og
> > dermed kun tillade sortering på de yderligere attributter tabellen har?
>
> Fordi den ordning, man får ved at sortere efter primærnøglerne ikke bør
> kunne brugees til noget. Et hvert program, der reelt bruger sortering
> efter nøgler, er bygget på en eller anden form for dårligt design.

Den tror jeg, at jeg vil lade stå.

> Det svarer lidt til at begynde at sortere efter pointere i c.

Nej, det gør det ikke. Pointere i c refererer til noget - og bliver ikke
refereret til (jo, det kan man godt, men så er der en anden pointer der
refererer til den).

> Det skal lige indskydes at jeg tager udgangspunkt i eksemplet, hvor der
> bruges blinde nøgler der (som nævnt ovenfor) kun bruges til at referere
> til andre tupler. Hvis man f. eks. bruger et personnavn som primærnøgle,
> kan man selvfølgelig godt sortere efter den. Den type situationer
> udtaler jeg mig ikke om.

Samme problematik som ovenfor. En nøgle definerer den pågældende tuppel
entydigt i den pågældende tabel, så man kan referere til netop denne tuppel
i denne tabel fra andre tabeller. Den bruges ikke til at referere til andre
tupler.

> Der er en enkelt undtagelse, og det er hvis man har et program, som på
> en eller anden måde har brug for at foretage et join eller på anden måde
> benytte primærnøgleværdierne internt - f. eks. ift. data trukket ud
> fra andre tabeller. Principielt set har man jo ikke den slags
> situationer, men et er teori og andet er praksis.

I don't get it.

> Det jeg advokerer imod, er at lave programmer, som f. eks. er afhængige
> af at primærnøglernes værdier oprettes i en bestemt rækkefølge, som man
> så bruger efterfølgende.

Det kan jeg da godt følge dig i. Men det mener jeg nu heller ikke at have
advokeret hverken for eller imod. Indeksstrukturen sørger vel netop for at
indeksere efter din nøgle så indsættelsesrækkefølgen ikke har betydning for
semantikken. Jeg er godt klar over at det kan have rent performancemæssigt.

Mvh
/Per

---

Per Jensen wrote:
> "Michael Zedeler" <michael@zedeler.dk> wrote in message
> news:%ANef.444$Cl2.4017@news000.worldonline.dk...
>
>>Der er ingen prædefineret naturlig ordning af forespørgsler uden ORDER
>>BY. Ved at bruge ORDER BY, får man forespørgsler, der performer
>>væsentligt dårligere, end uden.
>
>
> Nej, det er rigtigt. I SQL er der ingen prædefineret ordning - det bruger
> man jo netop ORDER BY til. Men vi kan vel godt blive enige om er der findes
> en ordning når databasen skal evaluere en SQL-forespørgsel uden en ORDER BY
> del i. Derfor _formodede_ jeg at den ville benytte primærnøglen eftersom jeg
> _formodede_ og stadigvæk _formoder_ at den indekserer sine data efter i den
> underliggende indeksstruktur. Jeg formoder dette da jeg dårligt kan
> forestille mig bedre performance end at databasen læser sine data
> sekventielt fra den underliggende indeksstruktur.

Jeg kan ikke se hvordan det kan være nogen god idé at basere sit design
på den slags formodninger.

>>>>Det er noget skidt, da primærnøglen som sådan ikke bør bære den type
>>>>information. Hvis der er behov for at sortere i en bestemt rækkefølge,
>>>>skal man kunne gøre det på et af felterne, som ikke optræder som nøgle.
>>>
>>>Hvilken type information taler du om her?
>>
>>Information der kan bruges til andet end at referere til andre tupler.
>
Jeg var ikke præcis nok, da jeg skrev ovenstående. Det ovenstående er
selvfølgelig en fremmednøgle. En primærnøgle er så information, der
bruges til at indentificere en tupel entydigt.

> Hvordan definerer du en primærnøgle? Jeg definerer en primærnøgle som en
> samling af attributter (evt. kun en enkelt) der entydigt identificerer en
> hel tuple i en relation/tabel. Efter den definition bruges primærnøglen ikke
> til at referere til andre tupler - andre tupler i _andre_ tabeller kan
> derimod referere til tuplerne i vores tabel vha. primærnøglen. Det er ikke
> det samme.

Jeps.

>>Det svarer lidt til at begynde at sortere efter pointere i c.
>
> Nej, det gør det ikke. Pointere i c refererer til noget - og bliver ikke
> refereret til (jo, det kan man godt, men så er der en anden pointer der
> refererer til den).

Det er jo to sider af samme sag. Eksemplet er for så vidt lige så
gyldigt, uanset om man sorterer efter pointeres værdi, eller
datastrukturer efter deres placering i hukommelsen.

>>Det skal lige indskydes at jeg tager udgangspunkt i eksemplet, hvor der
>>bruges blinde nøgler der (som nævnt ovenfor) kun bruges til at referere
>>til andre tupler. Hvis man f. eks. bruger et personnavn som primærnøgle,
>>kan man selvfølgelig godt sortere efter den. Den type situationer
>>udtaler jeg mig ikke om.
>
> Samme problematik som ovenfor. En nøgle definerer den pågældende tuppel
> entydigt i den pågældende tabel, så man kan referere til netop denne tuppel
> i denne tabel fra andre tabeller. Den bruges ikke til at referere til andre
> tupler.

Og igen: det er ikke væsentligt om der er tale om primær- eller
fremmednøgler. Problemet er det samme.

>>Det jeg advokerer imod, er at lave programmer, som f. eks. er afhængige
>>af at primærnøglernes værdier oprettes i en bestemt rækkefølge, som man
>>så bruger efterfølgende.
>
> Det kan jeg da godt følge dig i. Men det mener jeg nu heller ikke at have
> advokeret hverken for eller imod. Indeksstrukturen sørger vel netop for at
> indeksere efter din nøgle så indsættelsesrækkefølgen ikke har betydning for
> semantikken. Jeg er godt klar over at det kan have rent performancemæssigt.

Du kan selvfølgelig altid hælde en ORDER BY <primærnøgle> på
enforespørgsel, men jeg kan ikke lige se hvad man kan få ud af det,
andet end forespørgsler, der kører langsommere. Hvis man endelig får
noget ud af det, er det ihmo tegn på at man har lavet en fejl i sit
design. Dog med de undtagelser, du ikke forstod ovenfor. Måske det var
en idé med nogle eksempler?

Mvh. Michael.
--
Visit my home page at http://michael.zedeler.dk/
Get my vcard at http://michael.zedeler.dk/vcard.vcf

---

"Michael Zedeler" <michael@zedeler.dk> wrote in message news:rj_ef.483> >
> > Nej, det er rigtigt. I SQL er der ingen prædefineret ordning - det
bruger
> > man jo netop ORDER BY til. Men vi kan vel godt blive enige om er der
findes
> > en ordning når databasen skal evaluere en SQL-forespørgsel uden en ORDER
BY
> > del i. Derfor _formodede_ jeg at den ville benytte primærnøglen eftersom
jeg
> > _formodede_ og stadigvæk _formoder_ at den indekserer sine data efter i
den
> > underliggende indeksstruktur. Jeg formoder dette da jeg dårligt kan
> > forestille mig bedre performance end at databasen læser sine data
> > sekventielt fra den underliggende indeksstruktur.
>
> Jeg kan ikke se hvordan det kan være nogen god idé at basere sit design
> på den slags formodninger.

Jeg har ikke talt om godt eller dårligt design på noget tidspunkt.
Jeg ønskede blot at løse "problemet" med den manglende ordning, hvilket var
grunden at foreslår at man kunne benytte primærnøglen, som jeg mener giver
tabellens "naturlige" ordning.

> >>Information der kan bruges til andet end at referere til andre tupler.
> >
> Jeg var ikke præcis nok, da jeg skrev ovenstående. Det ovenstående er
> selvfølgelig en fremmednøgle. En primærnøgle er så information, der
> bruges til at indentificere en tupel entydigt.

Ja, som jeg netop skrev i forrige besked.

> >>Det svarer lidt til at begynde at sortere efter pointere i c.
> >
> > Nej, det gør det ikke. Pointere i c refererer til noget - og bliver ikke
> > refereret til (jo, det kan man godt, men så er der en anden pointer der
> > refererer til den).
>
> Det er jo to sider af samme sag. Eksemplet er for så vidt lige så
> gyldigt, uanset om man sorterer efter pointeres værdi, eller
> datastrukturer efter deres placering i hukommelsen.

Den semantiske betydning er da langt fra den samme. Du sammenligner noget
der entydigt definerer en tuppel og noget som refererer til en tuppel. Jeg
kan se mening med at sortere efter nøgler, men ikke fremmednøgler.

> >>Det skal lige indskydes at jeg tager udgangspunkt i eksemplet, hvor der
> >>bruges blinde nøgler der (som nævnt ovenfor) kun bruges til at referere
> >>til andre tupler. Hvis man f. eks. bruger et personnavn som primærnøgle,
> >>kan man selvfølgelig godt sortere efter den. Den type situationer
> >>udtaler jeg mig ikke om.
> >
> > Samme problematik som ovenfor. En nøgle definerer den pågældende tuppel
> > entydigt i den pågældende tabel, så man kan referere til netop denne
tuppel
> > i denne tabel fra andre tabeller. Den bruges ikke til at referere til
andre
> > tupler.
>
> Og igen: det er ikke væsentligt om der er tale om primær- eller
> fremmednøgler. Problemet er det samme.

Nej, det mener jeg bestemt ikke. Nøglen kan sige noget om de tupler der er i
den pågældende tabel. Det kan jeg ikke umiddelbart overføre på fremmnøgler.

> Du kan selvfølgelig altid hælde en ORDER BY <primærnøgle> på
> enforespørgsel, men jeg kan ikke lige se hvad man kan få ud af det,
> andet end forespørgsler, der kører langsommere. Hvis man endelig får
> noget ud af det, er det ihmo tegn på at man har lavet en fejl i sit
> design. Dog med de undtagelser, du ikke forstod ovenfor. Måske det var
> en idé med nogle eksempler?

Jamen, jeg må da beklage, at jeg ikke har forstået hvad du skriver.
Langsommere end hvad? Hvis indeksstrukturen er dannet ud fra primærnøglen,
som du ønsker at sortere efter vil databasen jo netop returnere alle
tuplerne i tabellen ved at scanne lineært gennem indeksstrukturen. Det har
jeg altså meget svært ved at se hvordan der kan være langsomt. Og
stadigvæk - i forhold til hvad? Såfremt en forespørgsel uden en ORDER BY del
skal evalueres vil det hurtigste stadigvæk være at scanne lineært gennem
indeksstrukturen.

Mvh
/Per

---

Per Jensen wrote:
>>>underliggende indeksstruktur. Jeg formoder dette da jeg dårligt kan
>>>forestille mig bedre performance end at databasen læser sine data
>>>sekventielt fra den underliggende indeksstruktur.
>>
>>Jeg kan ikke se hvordan det kan være nogen god idé at basere sit design
>>på den slags formodninger.
>
> Jeg har ikke talt om godt eller dårligt design på noget tidspunkt.
> Jeg ønskede blot at løse "problemet" med den manglende ordning, hvilket var
> grunden at foreslår at man kunne benytte primærnøglen, som jeg mener giver
> tabellens "naturlige" ordning.

Fair nok.
>>Det er jo to sider af samme sag. Eksemplet er for så vidt lige så
>>gyldigt, uanset om man sorterer efter pointeres værdi, eller
>>datastrukturer efter deres placering i hukommelsen.
>
> Den semantiske betydning er da langt fra den samme. Du sammenligner noget
> der entydigt definerer en tuppel og noget som refererer til en tuppel. Jeg
> kan se mening med at sortere efter nøgler, men ikke fremmednøgler.

Jeg kan godt komme på nogle situationer hvor man faktisk ender med at
sortere efter både primær- og fremmednøgler, men det er til
batch-processering af data, hvor ordningen som sådan ikke er vigtig, men
snarere det, at man på den måde modtager data, der skal behandles på
samme tid nogenlunde samtidigt.

F. eks.:

tabel1: feltet id er primærnøgle
tabel2: feltet pk er fremmednøgle (henviser til id i tabellen ovenfor)

De to tabeller bor i hver deres database og man vil gerne lave et
naturligt join imellem dem. I så fald er det oplagt at sortere efter
både primær- og fremmednøgle, når man henter data fra de to tabeller.

>>Og igen: det er ikke væsentligt om der er tale om primær- eller
>>fremmednøgler. Problemet er det samme.
>
> Nej, det mener jeg bestemt ikke. Nøglen kan sige noget om de tupler der er i
> den pågældende tabel. Det kan jeg ikke umiddelbart overføre på fremmnøgler.

Se mit eksempel ovenfor.

>>Du kan selvfølgelig altid hælde en ORDER BY <primærnøgle> på
>>enforespørgsel, men jeg kan ikke lige se hvad man kan få ud af det,
>>andet end forespørgsler, der kører langsommere. Hvis man endelig får
>>noget ud af det, er det ihmo tegn på at man har lavet en fejl i sit
>>design. Dog med de undtagelser, du ikke forstod ovenfor. Måske det var
>>en idé med nogle eksempler?
>
> Jamen, jeg må da beklage, at jeg ikke har forstået hvad du skriver.
> Langsommere end hvad? Hvis indeksstrukturen er dannet ud fra primærnøglen,
> som du ønsker at sortere efter vil databasen jo netop returnere alle
> tuplerne i tabellen ved at scanne lineært gennem indeksstrukturen.

Der er ingen garanti for at databasen vil returnere tabellens indhold i
den rækkefølge, primærnøgleindekset anfører. Hvis der f. eks. er tale om
en hashtabel, virker det f. eks. temmelig underligt hvis databasen
skulle returnere rækkerne efter stigende id.

Desuden kan man vel forestille sig at tabellen er fordelt på nogle
blokke, som slet ikke ligger i nogen logisk rækkefølge.

> Det har
> jeg altså meget svært ved at se hvordan der kan være langsomt. Og
> stadigvæk - i forhold til hvad? Såfremt en forespørgsel uden en ORDER BY del
> skal evalueres vil det hurtigste stadigvæk være at scanne lineært gennem
> indeksstrukturen.

Hvad jeg mener med "langsomt" er helt præcist "langsomt i forhold til
ikke at bruge ORDER BY". Hverken mere eller mindre.

Når du begynder at skrive om indeksstrukturer, så lyser der igen en rød
lampe hos mig, for ja - det er da rart at vide noget om hvordan
databaser er implementeret, men det er altså en dårlig idé at basere sin
kode på implementationsspecifikke antagelser.

Mvh. Michael.
--
Visit my home page at http://michael.zedeler.dk/
Get my vcard at http://michael.zedeler.dk/vcard.vcf

---

On Wed, 16 Nov 2005 18:19:28 +0100, Michael Zedeler
<michael@zedeler.dk> wrote:

>> I det tilfælde hvor så vil have rækkerne ud i deres "naturlige" rækkefølge
>> som Kim beder om vil jeg umiddelbart mene at man kan angive primærnøglen i
>> sin ORDER BY del.
>
>Det er noget skidt, da primærnøglen som sådan ikke bør bære den type
>information. Hvis der er behov for at sortere i en bestemt rækkefølge,
>skal man kunne gøre det på et af felterne, som ikke optræder som nøgle.

Inden jeg fortsætter: hvad mener du en god primærnøgle er..ex: en
ordinær tabel med en kundes stamoplysninger (navn, adresse bla bla) -
hvad kunne du da forestille dig som primærnøgle?

--

For nogle år tilbage designede jeg et system til en kunde. En del af
designet var en tabel:

Tidspunkt   | DateTime
MedarbejderID   | Tal

Intet andet. Ingen nøgle.

Data i tabellen kom fra en VB-applikation, der modtog data fra en
stregkodelæser på COM-porten.

For nylig blev applikationen lavet i VB.Net. Jeg kom desværre til at
lave en ikke ualmindelig programmeringsfejl, idet der i koden blev
byttet rundt på dag/måned.

01-09-2005 og 09-01-2005 blev nu mixet sammen, og jeg havde ikke
mulighed for at kunne se, hvad der var hvad.

Dengang denne noget simple tabel blev designet, ville jeg ønske den
havde haft, hvad mine tabeller ALTID har i dag: en autonummerering.
Det ville have givet mig mulighed for at finde og konvertere de
forkert oprettede poster. Den mulighed missede jeg.

I dag opretter jeg aldrig en tabel, uden en fortløbende nøgle.

mvh /Snedker
---

---

Morten Snedker wrote:
> On Wed, 16 Nov 2005 18:19:28 +0100, Michael Zedeler
> <michael@zedeler.dk> wrote:
>
>
>>>I det tilfælde hvor så vil have rækkerne ud i deres "naturlige" rækkefølge
>>>som Kim beder om vil jeg umiddelbart mene at man kan angive primærnøglen i
>>>sin ORDER BY del.
>>
>>Det er noget skidt, da primærnøglen som sådan ikke bør bære den type
>>information. Hvis der er behov for at sortere i en bestemt rækkefølge,
>>skal man kunne gøre det på et af felterne, som ikke optræder som nøgle.
>
> Inden jeg fortsætter: hvad mener du en god primærnøgle er..ex: en
> ordinær tabel med en kundes stamoplysninger (navn, adresse bla bla) -
> hvad kunne du da forestille dig som primærnøgle?

Det afhænger af hvad det skal bruges til. For personer kan det være et
almindeligt autonummerfelt eller - hvis det er til brug i danmark alene
- vedkommenes personnummer.

> For nogle år tilbage designede jeg et system til en kunde. En del af
> designet var en tabel:
>
>[klip]
>
> Dengang denne noget simple tabel blev designet, ville jeg ønske den
> havde haft, hvad mine tabeller ALTID har i dag: en autonummerering.
> Det ville have givet mig mulighed for at finde og konvertere de
> forkert oprettede poster. Den mulighed missede jeg.
>
> I dag opretter jeg aldrig en tabel, uden en fortløbende nøgle.
Det er så ikke et eksempel på kode, der gør brug af antagelsen, men
snarere desparat brandslukning, hvor alle kneb gælder. I sådan situation
kan man lige så vel ende med at skulle lave et join imellem to tabeller,
alene baseret på personnavne eller det, der er værre.

Jeg er altså ikke modstander af autonummerfelter som primærnøgler(!).
Jeg er modstander af kode, der gør den antagelse at man får noget ud af
at sortere efter disse nøglers værdier.

Mvh. Michael.
--
Visit my home page at http://michael.zedeler.dk/
Get my vcard at http://michael.zedeler.dk/vcard.vcf

---

On Thu, 17 Nov 2005 13:23:47 +0100, Michael Zedeler
<michael@zedeler.dk> wrote:


--klip

>Jeg er altså ikke modstander af autonummerfelter som primærnøgler(!).
>Jeg er modstander af kode, der gør den antagelse at man får noget ud af
>at sortere efter disse nøglers værdier.

Så lad mig spørge på en anden måde: hvornår mener du et autonummereret
felt er praktisk?

mvh /Snedker
---

---

Morten Snedker wrote:
> On Thu, 17 Nov 2005 13:23:47 +0100, Michael Zedeler
> <michael@zedeler.dk> wrote:
>
>>Jeg er altså ikke modstander af autonummerfelter som primærnøgler(!).
>>Jeg er modstander af kode, der gør den antagelse at man får noget ud af
>>at sortere efter disse nøglers værdier.
>
> Så lad mig spørge på en anden måde: hvornår mener du et autonummereret
> felt er praktisk?

Til at autogenerere primærnøgler. Intet andet.

Mvh. Michael.
--
Visit my home page at http://michael.zedeler.dk/
Get my vcard at http://michael.zedeler.dk/vcard.vcf

---

Michael Zedeler skrev:

> Det jeg advokerer imod, er at lave programmer, som f. eks. er
> afhængige af at primærnøglernes værdier oprettes i en bestemt
> rækkefølge, som man så bruger efterfølgende.

Vil det sige at du mener at autonummerfelter som primærnøgler er en
dårlig ide?

I mine øjne er et autonummerfelt ganske praktisk - også i forhold
til sortering. Nummeret indeholder ikke nogen oplysning i sig selv,
men fordi det er jævnt stigende, kan det bruges til at sortere
poster efter oprettelsestidspunkt. Det holder selvfølgelig ikke i
et replikeret miljø, men hvis man ikke bruger replikering, er
autonummeret i mine øjne ganske praktisk.
--
Jens Gyldenkærne Clausen
Svar venligst under det du citerer, og citer kun det der er
nødvendigt for at forstå dit svar i sammenhængen. Se hvorfor og
hvordan på http://usenet.dk/netikette/citatteknik.html

---

Jens Gyldenkærne Clausen wrote:
> Michael Zedeler skrev:
>
>>Det jeg advokerer imod, er at lave programmer, som f. eks. er
>>afhængige af at primærnøglernes værdier oprettes i en bestemt
>>rækkefølge, som man så bruger efterfølgende.
>
> Vil det sige at du mener at autonummerfelter som primærnøgler er en
> dårlig ide?

Nej.

> I mine øjne er et autonummerfelt ganske praktisk - også i forhold
> til sortering. Nummeret indeholder ikke nogen oplysning i sig selv,
> men fordi det er jævnt stigende, kan det bruges til at sortere
> poster efter oprettelsestidspunkt. Det holder selvfølgelig ikke i
> et replikeret miljø, men hvis man ikke bruger replikering, er
> autonummeret i mine øjne ganske praktisk.

Hvis du en dag får brug for at bytte rundt på rækkefølgen, dine poster
sorteres efter, har sorteret efter primærnøglen 117 forskellige steder i
din kode og samtidig har et hav af tabeller med fremmednøgler, der
refererer til din primærnøgle, så har du et rigtigt irriterende problem.
Men det er vel ikke uden grund at Sybase har cascading updates af nøgler...

Hvis man er den eneste udvikler og ved hvad man gør, kan man slippe
afsted med mange, grimme ting, men generelt det er en dårlig idé fordi
at princippet afhænger af en masse faktorer, man egentlig ikke har
specielt godt styr på. For det første er der systemer hvor der ikke
findes autonummerering, men andre metoder til at generer id'er. Hvis man
er igang med et stort projekt med flere udviklere, er det noget skidt at
have som ekstra krav, at id-generatoren skal generere id'er i
rækkefølge. Derudover kan man ikke vide om der på sigt bliver behov for
at ændre rækkefølgen, hvilket kan blive meget svært at løse uden at
skulle dumpe hele databasen og genindlæse den igen.

Jeg synes at det ovenstående er noget af et minefelt, som jeg nok en
gang for alle ville undgå ved at tilføje et felt, man kan bruge til
sortering efter. Det koster ikke meget i ekstra plads og har den rare
egenskab at det står en fuldstændig frit for at ændre sorteringsrækkefølgen.

Mvh. Michael.
--
Visit my home page at http://michael.zedeler.dk/
Get my vcard at http://michael.zedeler.dk/vcard.vcf

---

Michael Zedeler skrev:

> Hvis du en dag får brug for at bytte rundt på rækkefølgen,
> dine poster sorteres efter, har sorteret efter primærnøglen
> 117 forskellige steder i din kode og samtidig har et hav af
> tabeller med fremmednøgler, der refererer til din primærnøgle,
> så har du et rigtigt irriterende problem.

Jeg er ikke helt med. Hvis jeg har brug for at sortere i en given
rækkefølge, må jeg nødvendigvis have et felt (evt. flere) der kan
give mig den ønskede rækkefølge. Den rækkefølge jeg får ved at
sortere efter et autonummerfelt, er den rækkefølge posterne er
oprettet i.

Det er ikke muligt at ændre den rækkefølge posterne er oprettet i
uden at "snyde" - når en post er oprettet kan tidspunktet for
oprettelsen, og mere specifikt forholdet mellem poster der var
oprettet i forvejen, den aktuelle post og poster der oprettes
senere, ikke ændres.

Jeg er enig i at det kan være et problem hvis man forsøger at lægge
ekstrainformationer ind i et autonummerfelt - som det fx ses når
nogle forsøger at få et autonummerfelt til at afspejle postens
placering i databasen. Men jeg kan ikke se at man skal undlade at
sortere på et autonummerfelt, blot fordi det en dag kan blive
nødvendigt at ændre sorteringen.

Hvis man får brug for at sortere på et felt der kan opdateres, kan
det tilføjes når behovet opstår. I mange tilfælde er det rigeligt
med en sortering der ordner posterne efter oprettelsestidspunkt.
--
Jens Gyldenkærne Clausen
Svar venligst under det du citerer, og citer kun det der er
nødvendigt for at forstå dit svar i sammenhængen. Se hvorfor og
hvordan på http://usenet.dk/netikette/citatteknik.html

---

Jens Gyldenkærne Clausen wrote:
> Michael Zedeler skrev:
>
>
>>Hvis du en dag får brug for at bytte rundt på rækkefølgen,
>>dine poster sorteres efter, har sorteret efter primærnøglen
>>117 forskellige steder i din kode og samtidig har et hav af
>>tabeller med fremmednøgler, der refererer til din primærnøgle,
>>så har du et rigtigt irriterende problem.
>
> Jeg er ikke helt med. Hvis jeg har brug for at sortere i en given
> rækkefølge, må jeg nødvendigvis have et felt (evt. flere) der kan
> give mig den ønskede rækkefølge. Den rækkefølge jeg får ved at
> sortere efter et autonummerfelt, er den rækkefølge posterne er
> oprettet i.

Ikke nødvendigvis. Hvis du f. eks. har importeret data fra andre kilder
(f. eks. ved sammenlægning af to systemer), er det ikke længere
rækkefølgen, posterne er oprettet i. Du rammer netop præcis min pointe:
autonummereringen forandlediger folk til at gøre antagelser om værdierne
i sådan et primærnøglefelt, som kan give problemer senere hen.

> Det er ikke muligt at ændre den rækkefølge posterne er oprettet i
> uden at "snyde" - når en post er oprettet kan tidspunktet for
> oprettelsen, og mere specifikt forholdet mellem poster der var
> oprettet i forvejen, den aktuelle post og poster der oprettes
> senere, ikke ændres.

Se mit eksempel ovenfor.

> Jeg er enig i at det kan være et problem hvis man forsøger at lægge
> ekstrainformationer ind i et autonummerfelt - som det fx ses når
> nogle forsøger at få et autonummerfelt til at afspejle postens
> placering i databasen. Men jeg kan ikke se at man skal undlade at
> sortere på et autonummerfelt, blot fordi det en dag kan blive
> nødvendigt at ændre sorteringen.

Du gør den implicitte antagelse at poster med autonummerfelter er
oprettet i den rækkefølge, man får når man sorterer efter disse numre.
Hvis du en dag som konsulent kommer til en virksomhed med en masse
poster i en tabel med autonummerering på et felt, vil du da automatisk
konkludere: "aha - de er oprettet i den rækkefølge, jeg får ved at
sortere efter nøglen". Nej, vel? Ergo er det ikke nogen god idé at antage.

> Hvis man får brug for at sortere på et felt der kan opdateres, kan
> det tilføjes når behovet opstår. I mange tilfælde er det rigeligt
> med en sortering der ordner posterne efter oprettelsestidspunkt.

Som jeg så mener er dårligt design.

Mvh. Michael.
--
Visit my home page at http://michael.zedeler.dk/
Get my vcard at http://michael.zedeler.dk/vcard.vcf

---

Michael Zedeler skrev:

> Ikke nødvendigvis. Hvis du f. eks. har importeret data fra
> andre kilder (f. eks. ved sammenlægning af to systemer), er
> det ikke længere rækkefølgen, posterne er oprettet i.

Jeg mener at en sådan sammenlægning er et specialtilfælde, på samme
måde som en replikeret database vil være det. Det er i mine øjne
overkill at diskvalificere autonummersortering på grund af en
situation der kun opstår i ganske få tilfælde. Men jeg er da enig i
at man skal være opmærksom på hvad der sker hvis man importerer
data fra andre tabeller.


> Hvis du en dag som konsulent kommer til en
> virksomhed med en masse poster i en tabel med autonummerering
> på et felt, vil du da automatisk konkludere: "aha - de er
> oprettet i den rækkefølge, jeg får ved at sortere efter
> nøglen". Nej, vel?

Vil du automatisk antage at der nok er flettet data så autonummeret
ikke svarer til oprettelsesrækkefølgen?

Jeg ville i første omgang kigge på tabellen - der kan være andre
felter der viser kronologien, eller der kan være store spring i
autonummerværdierne der antyder at der har været ændret i
indholdet. Jeg ville også høre hvad virksomhedens egne folk kender
til databasen. I mange tilfælde vil det på denne måde være muligt
at afgøre om primærnøglesortering er brugbar.

I de tilfælde hvor det ikke kan lade sig gøre, er der næppe noget
brugbart alternativ - hvis man ikke kan afgøre om
primærnøglesortering svarer til posternes oprettelsesorden, er det
ikke muligt at få sorteret tabellen i denne orden (hvis der var et
eller flere felter man kunne sortere efter, kunne de også bruges
til at sammenligne med en primærnøglesortering).
--
Jens Gyldenkærne Clausen
Svar venligst under det du citerer, og citer kun det der er
nødvendigt for at forstå dit svar i sammenhængen. Se hvorfor og
hvordan på http://usenet.dk/netikette/citatteknik.html

---

Jens Gyldenkærne Clausen wrote:
> Michael Zedeler skrev:
>
>>Ikke nødvendigvis. Hvis du f. eks. har importeret data fra
>>andre kilder (f. eks. ved sammenlægning af to systemer), er
>>det ikke længere rækkefølgen, posterne er oprettet i.
>
> Jeg mener at en sådan sammenlægning er et specialtilfælde, på samme
> måde som en replikeret database vil være det. Det er i mine øjne
> overkill at diskvalificere autonummersortering på grund af en
> situation der kun opstår i ganske få tilfælde. Men jeg er da enig i
> at man skal være opmærksom på hvad der sker hvis man importerer
> data fra andre tabeller.

Hvordan vi vurderer situationen er måske en afspejling af, hvad for
opgaver, vi hver i sær arbejder med til daglig. Jeg har haft "snablen"
nede i rigitg mange, gamle systemer, hvor intet var hvad det foregav at
være. Det er også derfor jeg er pænt træt af udviklere, der runder
hjørner for lige at spare et felt eller den slags.

>>Hvis du en dag som konsulent kommer til en
>>virksomhed med en masse poster i en tabel med autonummerering
>>på et felt, vil du da automatisk konkludere: "aha - de er
>>oprettet i den rækkefølge, jeg får ved at sortere efter
>>nøglen". Nej, vel?
>
> Vil du automatisk antage at der nok er flettet data så autonummeret
> ikke svarer til oprettelsesrækkefølgen?

Jeg ville slet ikke antage noget som helst

> Jeg ville i første omgang kigge på tabellen - der kan være andre
> felter der viser kronologien, eller der kan være store spring i
> autonummerværdierne der antyder at der har været ændret i
> indholdet. Jeg ville også høre hvad virksomhedens egne folk kender
> til databasen. I mange tilfælde vil det på denne måde være muligt
> at afgøre om primærnøglesortering er brugbar.

Selvfølgelig kan man spørge sig for og prøve at undersøge dette og hint,
men inegn af de metoder, du nævner ovenfor er jo skudsikre og det er
desværre hvad man har brug for. I min tid som konsulent, har jeg været
ude for de mest absurde ting. F. eks. et firma hvis absolut vigtigste
aktiv var et stykke software, som de slev havde udviklet. De ville gerne
have at jeg skulle udvikle videre på det. Da jeg spurgte hvor kildekoden
var, vidste de det ikke. Det tog en uge bare at lokalisere de 4-5
forskellige versioner af deres system, de havde, og flette det hele
sammen i CVS igen.

Eksemplet er taget med bare for at illustrere hvor basale informationer,
der kan forsvinde i forvirringen.

> I de tilfælde hvor det ikke kan lade sig gøre, er der næppe noget
> brugbart alternativ - hvis man ikke kan afgøre om
> primærnøglesortering svarer til posternes oprettelsesorden, er det
> ikke muligt at få sorteret tabellen i denne orden (hvis der var et
> eller flere felter man kunne sortere efter, kunne de også bruges
> til at sammenligne med en primærnøglesortering).

Men jeg undrer mig stadigvæk over hvornår man har brug for rækkernes
oprettelsesorden. Hvis man har brug for den form for information,
opretter man jo et felt til det, som det famøse datofelt, hvor der ved
et uheld blev brugt to indbyrdes inkonsistente datoformater.

Mvh. Michael.
--
Visit my home page at http://michael.zedeler.dk/
Get my vcard at http://michael.zedeler.dk/vcard.vcf

---

Michael Zedeler skrev:

> Men jeg undrer mig stadigvæk over hvornår man har brug for
> rækkernes oprettelsesorden.

Det kan fx være for at vise den nyeste post. Det er også brugbart
hvis man fx vil slette alt andet end de nyeste 100 poster.
--
Jens Gyldenkærne Clausen
Svar venligst under det du citerer, og citer kun det der er
nødvendigt for at forstå dit svar i sammenhængen. Se hvorfor og
hvordan på http://usenet.dk/netikette/citatteknik.html

---

Jens Gyldenkærne Clausen wrote:
> Michael Zedeler skrev:
>
>>Men jeg undrer mig stadigvæk over hvornår man har brug for
>>rækkernes oprettelsesorden.
>
> Det kan fx være for at vise den nyeste post. Det er også brugbart
> hvis man fx vil slette alt andet end de nyeste 100 poster.

Jeg ville bruge et timestamp i stedet. Der er mange databaser, der selv
kan hælde dem på, når man opretter en række.

Men jeg kan da godt se, at hvis man har en tabel, der reelt ikke bruges
til historiske data, men mere kortvarig lagring (hvor man med faste
intervaller sletter gamle rækker), er løsningen med autonummerering oplagt.

Mvh. Michael.
--
Visit my home page at http://michael.zedeler.dk/
Get my vcard at http://michael.zedeler.dk/vcard.vcf

---

On Fri, 18 Nov 2005 00:24:46 +0100, Michael Zedeler
<michael@zedeler.dk> wrote:

>Jeg ville bruge et timestamp i stedet. Der er mange databaser, der selv
>kan hælde dem på, når man opretter en række.

Der er også en sjat databaser, hvor datofeltets opløsning ganske
enkelt er for dårligt (fx kun ned til ét sekund). Endnu værre er de
tilfælde, hvor folk absolut insisterer på at bruge unix timestamps,
hvor databasen måske endda kan tilbyde noget bedre.

--
- Peter Brodersen

---

Kim Hansen skrev:

> Saa kan man lave et felt med et tidsstempel der indeholder
> oprettelsestidspunktet og sortere efter det. Paa den maade kan
> man undgaa sortering efter syntetiske noegler.

Det er naturligvis korrekt. Spørgsmålet er bare om det også er
nødvendigt, hvis man ikke har brug for selve datoværdien.

Den ekstra plads et datofelt fylder, er nok til at leve med, men
hvis feltet skal bruges som effektiv søgenøgle, skal det vel også
indekseres. Det betyder at databasen så skal vedligeholde to indeks
til en sortering der kun kræver det ene.
--
Jens Gyldenkærne Clausen
Svar venligst under det du citerer, og citer kun det der er
nødvendigt for at forstå dit svar i sammenhængen. Se hvorfor og
hvordan på http://usenet.dk/netikette/citatteknik.html

---

"Jens Gyldenkærne Clausen" wrote

> Det er naturligvis korrekt. Spørgsmålet er bare om det også er
> nødvendigt, hvis man ikke har brug for selve datoværdien.

Det er et spørgsmål om at holde internal system logic og business logic
adskilt

In order to guarantee uniqueness, each table has a technical primary key (a
surrogate primary key populated by the create trigger with a unique sequence
value, but preferential a UUID), which will never get a business meaning.
Don't argue, primary keys with business meaning as well as composite keys
are a bad idea. There is nothing to say against additional unique columns
with business meaning, but do not merge the underlying technical
implementation with your business logic. (..)

http://www.smart-it-consulting.com/database/progress-database-design-guide/

- Peter

---

Peter Lykkegaard wrote:
> "Jens Gyldenkærne Clausen" wrote
>
>>Det er naturligvis korrekt. Spørgsmålet er bare om det også er
>>nødvendigt, hvis man ikke har brug for selve datoværdien.
>
> Det er et spørgsmål om at holde internal system logic og business logic
> adskilt
>
> In order to guarantee uniqueness, each table has a technical primary key (a
> surrogate primary key populated by the create trigger with a unique sequence
> value, but preferential a UUID), which will never get a business meaning.
> Don't argue, primary keys with business meaning as well as composite keys
> are a bad idea. There is nothing to say against additional unique columns
> with business meaning, but do not merge the underlying technical
> implementation with your business logic. (..)

Det indfanger sådan set essensen af det, jeg har prøvet at pointere hele
tiden.

Mvh. Michael.
--
Ingen er en alle kender, som ingen har mødt.
Ergo har ingen mødt sig selv.
Visit my home page at http://michael.zedeler.dk/
Get my vcard at http://michael.zedeler.dk/vcard.vcf

---

"Michael Zedeler" <michael@zedeler.dk> wrote in message
news:5x8ff.544$Cl2.4355@news000.worldonline.dk...
>
> Det indfanger sådan set essensen af det, jeg har prøvet at pointere hele
> tiden.

Godt så.
Så fik du endelig ret i den praktiske holdning til den ting

Kunne vi så måske finde en løsning til Kim (som jeg desværre kom til at give
mit teoretiske bud på). Eftersom jeg ikke har lyst til at gisne mere om den
interne ordning tabellerne har (som Kim nævner) går jeg ud fra der findes en
attribut der angiver "tabellens naturlige ordning".

Mvh
/Per

---

"Per Jensen" wrote

> Kunne vi så måske finde en løsning til Kim (som jeg desværre kom til at
> give
> mit teoretiske bud på). Eftersom jeg ikke har lyst til at gisne mere om
> den
> interne ordning tabellerne har (som Kim nævner) går jeg ud fra der findes
> en
> attribut der angiver "tabellens naturlige ordning".
>
Den naturlige ordning er den ordning eller rækkefølge som MSSQL giver
dataene
Der skal evt laves et et nyt beregnet felt som man kan sortere på
efterfølgende

Tidligere forslag:

> SELECT col, 1 as tsort FROM t1
> UNION
> SELECT col, 2 FROM t2
> UNION
> SELECT col, 3 FROM t3
> ORDER BY tsort, col

SELECT * FROM (
SELECT col FROM t1
UNION
SELECT col FROM t2
UNION
SELECT col FROM t3)
ORDER BY col

Burde give:

col
----
a1
b1
c1
a2
b2
c2
....
an
bn
cn

- Peter

---

"Peter Lykkegaard" <plykkegaard@gmail.com> wrote in message
news:437d838e$0$204$edfadb0f@dread16.news.tele.dk...
>
> SELECT * FROM (
> SELECT col FROM t1
> UNION
> SELECT col FROM t2
> UNION
> SELECT col FROM t3)
> ORDER BY col
>
> Burde give:
>
> col
> ----
> a1
> b1
> c1
> a2
> b2
> c2
> ...
> an
> bn
> cn

Hvilke værdier antager du så col attributten har i de forskellige tabeller?
Jeg mener bare, at hvis col har værdien 1-n i alle tabeller, kan man så ikke
risikere at få følgende resultat:
> col
> ----
> c1
> b1
> a1
> b2
> c2
> a2
> ...
> an
> bn
> cn

Eller...?

Mvh
/Per

---

"Per Jensen" wrote

> Hvilke værdier antager du så col attributten har i de forskellige
> tabeller?

Jeg antager ikke noget, attributten bliver sorteret efter den værdi den
måtte have
Derfor kan et beregnet felt være nødvendigt for at give en bedre sortering

> Jeg mener bare, at hvis col har værdien 1-n i alle tabeller, kan man så
> ikke
> risikere at få følgende resultat:

>> col
>> ----
>> c1
>> b1
>> a1

Jeg forudsætter at c1, b1, a1 er de "rigtige" værdier, det er den viden vi
har pt

Ved at sætte den select statement med union etc i parentes og sætte order by
prædikat udenfor så bliver der sorteret i det view der bliver genereret

- Peter

---

Per Jensen wrote:

> Kunne vi så måske finde en løsning til Kim (som jeg desværre kom til at give
> mit teoretiske bud på).

Det kan vel altid klares med et subselect?

SELECT DISTINCT (
   SELECT * FROM tabel 1
   UNION
   ...
) ORDER BY 1

Mvh. Michael.
--
Visit my home page at http://michael.zedeler.dk/
Get my vcard at http://michael.zedeler.dk/vcard.vcf

---

Michael Zedeler wrote:
>
> SELECT DISTINCT (
> SELECT * FROM tabel 1

Ups: tabel 1 -> tabel1

Ellers det samme, altså:

SELECT DISTINCT (
SELECT * FROM tabel1
UNION
...
) ORDER BY 1

Mvh. Michael.
--
Visit my home page at http://michael.zedeler.dk/
Get my vcard at http://michael.zedeler.dk/vcard.vcf

---

On Wed, 16 Nov 2005 13:07:53 +0100
Jens Gyldenkærne Clausen <jens@gyros.invalid> wrote:

> Kim Schulz skrev:
>
> > skal have 3 kolonner (en fra hver af 3 tabeller) til at blive
> > kombineret i en kolonne
> > fra dette:
> > t1.col t2.col t3.col
>
>
> Du skal bruge en UNION-forespørgsel:
>
>    SELECT col FROM t1
>    UNION
>    SELECT col FROM t2
>    UNION
>    SELECT col FROM t3
>
> Dubletter bliver automatisk frasorteret (det kan undgås med
> UNION ALL).
>
> Lidt ekstra info:
> - Første select bestemmer kolonnenavnene.
> - Kolonnetyperne skal matche i alle medvirkende selects (de skal
> kunne sættes sammen uden et cast).
> - Det er muligt at sortere ved at angiver ORDER BY efter sidste
> select.
>
> > kan det lade sig gøre? (MSSQL)
>
> Se evt. UNION i onlinehjælpen (BOL).

Da data rækkefølge og indhold er meget random er der ikke umiddelbart
noget man kan ordne efter. De er ordnet internt i hver tabel men ikke
efter noget som kan forholdes til de andres ordninger.
Desuden så vil det du beskriver give noget ala a1
a2
a3
..
..
b1
b2
b3
..
..
c1
c2
c3
..
..

---

Jens Gyldenkærne Clausen <jens@gyros.invalid> writes:

> Hvis man får brug for at sortere på et felt der kan opdateres, kan
> det tilføjes når behovet opstår. I mange tilfælde er det rigeligt
> med en sortering der ordner posterne efter oprettelsestidspunkt.

Saa kan man lave et felt med et tidsstempel der indeholder
oprettelsestidspunktet og sortere efter det. Paa den maade kan man
undgaa sortering efter syntetiske noegler.

--
Kim Hansen

---

"Per Jensen" <pbj@nospam.cs.aau.dk> writes:

> "Michael Zedeler" <michael@zedeler.dk> wrote in message
> news:%ANef.444$Cl2.4017@news000.worldonline.dk...
>>
>> Der er ingen prædefineret naturlig ordning af forespørgsler uden ORDER
>> BY. Ved at bruge ORDER BY, får man forespørgsler, der performer
>> væsentligt dårligere, end uden.
>
> Nej, det er rigtigt. I SQL er der ingen prædefineret ordning - det bruger
> man jo netop ORDER BY til. Men vi kan vel godt blive enige om er der findes
> en ordning når databasen skal evaluere en SQL-forespørgsel uden en ORDER BY
> del i.

Nej, der er _ingen_ ordning naar man ikke bruger ORDER BY. Hvis den
samme forespoergelse uden ORDER BY bliver udfoert to gange samtidig,
kan en SQL-database godt returnere de samme raekker i forskellig
raekkefoelge i de to resultater.

> Derfor _formodede_ jeg at den ville benytte primærnøglen eftersom jeg
> _formodede_ og stadigvæk _formoder_ at den indekserer sine data efter i den
> underliggende indeksstruktur. Jeg formoder dette da jeg dårligt kan
> forestille mig bedre performance end at databasen læser sine data
> sekventielt fra den underliggende indeksstruktur.

Har du afproevet det? Jeg ved at postgresql ikke fungere paa den
maade, der saettes data ind der hvor der er plads, i starten vil ting
placeres i den raekkefoelge som de oprettes og senere vil de blive sat
ind der hvor der er slettet data hvis der har vaeret koert vacuum. Man
kan dog opnaa en ordning i tabellen ved brug af CLUSTER kommandoen,
men det er ikke noget der findes i SQL-standarden.
http://www.postgresql.org/docs/8.0/interactive/sql-cluster.html
Og den ordning bliver ikke vedligeholdt ved indsaettelse af ny data,
den kraever en jaevnlig koersel af CLUSTER.

--
Kim Hansen