Hur selectar man mot en sammansatt nyckel?

on t.col1 = q.col1
and t.col2 = q.col2

hej, tack.. fast det är lite mer jag glömde visa kom jag på.. innan jag kom på att det var en sammansatt nyckel skrev jag så ungefär så här (har ändrat namnen lite men i princip så..)

SELECT epost, namn, ansvarig
FROM namn ibn
INNER JOIN adresser iba ON ibn.n_id = iba.n_id
INNER JOIN epost ibe ON ibe.n_id = iba.n_id
WHERE len(epost) > 0
GROUP BY epost, namn, ansvarig
ORDER BY ibe.epost

adresser (tabellen)
n_id (PK) (ex: 1, 2, 3..)
adress
...

epost (tabellen)
n_id (key1 - PK) (ex: 1, 2, 3..)
epost_typ (key2 - PK) (ex:D, S)
epost
...

namn (tabellen)
n_id (PK) (ex: 1, 2, 3..)
snamn
...

Men det blev problem eftersom det var en sammansatt nyckel som jag måste använda (tror jag) för annars får jag dubletter av eposten.. eftersom

n_id epost_typ epost
5 D olle@abc.com
5 S olle@abc.com

och jag vill ha unik epost då..

SELECT DISTINCT epost, namn, ansvarig ....

5 D olle@abc.com
5 S olle@abc.com

Vilket av D eller S vill du ha då?

hejsan (satt inte framför datorn ett tag).. jo, jag provade DISTINCT men det blev ingen skillnad (kanske) eftersom JOIN är utformad som den är..?

Jo, jag vill i första hand ha D men om D inte finns så måste S användas.. det viktigaste är dock att det som SELECT genererar helst inte ger dubletter av eposten..

select n_id,min(epost_type),epost
from ...
group by n_id,epost

hmm.. jag fick 4 rader mer nu när jag selectar ID..?

Vilka kolumner är det du ska ha ut?

Jag vill lista

epost, namn, ansvarig (o sen övrig adressinformation) som finns i adress tabellen. Om man måste ta med mer kolumner för att frågan ska bli rätt är det okay också eftersom jag ju i efterhand kan välja vilka kolumner jag vill visa.. i GUIt alltså..

Ju färre kolumner desto smidigare....:)

Om du endast plockar ut "gemensamma" kolumner, dvs. hoppar över "epost_type" etc. så kommer det att fungera med DISTINCT.

Hur ser din fråga ut just nu, i "worst case scenario", dvs. med alla kolumner valda i GUI:t?

Hej, tack.. jo, jag började med att prova (för att veta om jag gjort rätt eller inte) att bara köra

SELECT distinct epost FROM epost
WHERE len(epost) > 0

och fick då det antal epost adresser som jag förmodar är unika.. sen bygger jag på med en kolumn i taget för att se effekten.. det största problemet är då, så som jag ser det, att primärnyckeln består av två kolumner, key1 key2, och att man får dubletter eftersom det inte finns en enda unik kolumn i tabellen epost.

Det var nån som föreslog att man kunde lägga till en ny, singel ID kolumn med automatisk counter inställd för att man skulle kunna göra en JOIN mot ett fält istället för två. Det har jag inte provat än iofs, men den räknaren kommer ju inte att alls att stämma rent relationsmässigt. T.ex: tidigare hade ju olle@abc.com det unika IDt [ 5 D ] och [ 5 S ] .. (det är här det blir problem för när jag gör även den enklaste SELECT med en JOIN för att få t.ex. en adress så gör jag ju det mot n_id o då kommer jag ofrånkomligen att, i det här fallet, få olle@abc.com listad 2 ggr eftersom n_id = 5 förekommer 2 grr). Men låt oss iaf anta att vi sätter ny extra ID kolumn.. nu får t.ex. olle@abc.com då även ID 200 och 201 ... visst, men när jag då gör en JOIN så ska ju 200 och 201 matcha ID 200 och 201 som finns i adress tabellen.. o det verkar ju bli helt fel..

.. går det att lösa enklare om key2 består av siffror eller nåt sånt..? för det kan jag ju ändra..

Jag satt o funderade lite på själva arbetsflödet o kom till sist fram till att syftet med listan inte krävde den implementation som jag först jobbade med.. det mesta gick att lösa med, en för mig, "vanlig" SQL.. =) även om det inte blev lika "snyggt".. iofs är det ju intressant att veta hur man skulle ha löst ovanstående om det hade funnits såna krav.. :)

(Det är ju förresten möjligt att MIN funktionen som LarsG föreslog (eller DISTINCT) hade räckt egentligen men att just den här databasen kanske var ovanligt uppbyggd eller nåt.. ) tack för alla svaren dock :)

Får man fråga varför du har flera primärnycklar på 1 tabell?. Mig veterligen kan man bara ha 1 primärnyckel på varje tabell.

natas skrev:

Får man fråga varför du har flera primärnycklar på 1 tabell?. Mig veterligen kan man bara ha 1 primärnyckel på varje tabell.

Han menar inte flera primärnycklar, han menar att flera attribut (än ett) ingår i hans primärnyckel. :)

Vad menar han då när han skriver:

col1, col2, col3 och col1, col2 utgör tillsammans en primärnyckel.

Och hur sätter man ihop 1 primärnyckel av flera kolumner?.

hej, såg inte att det var nya inlägg.. :)

om du gör i Enterprise Manager så skapar du två ID fält t.ex. o sen högerklickar du båda o sätter Primary Key..

annars kan du skriva

create table T1
(
id1 int,
id2 int,
...
primary key(id1, id2)
)

ungefär.. ibland vill man kanske att en post ska vara unik baserat på två id..

Intressant. Jag har aldrig använt composite keys. Men att använda flera kolumner för att få ihop 1 nyckel känns väldigt underligt, i vilka sammanhang kan de vara användbara?. I de allra flesta fallen är det ju surrogat och naturella nycklar som används.

Det faktum att du har en sammansatt nyckel är inget problem. Det enda du ska tänka på är att om du vill slippa dubletter så kan du inte plocka ut värden som som gör att mer än en rad måste plockas från de relaterade tabellerna, eller om så måste ske får du se till att endast ta ett värde, genom att använda MIN och MAX (som i LarsGs exempel).

Sammansatta nycklar är inget konstigt, utan en fundamental del av en databasdesign. Det finns ingen anledning att skapa någon slags artificiell nyckel, när det finns en konkret användbar sammansatt nyckel.

Men om du har 2 kolumner som tillsammans blir en composite key, hur sätter du FOREIGN KEY i child-tabellerna?.