Hur skriver man selectsatser som innehåller främmande nycklar?

Hur skrivs selectsatsen när man vill hämta information från en annan tabell, dvs en främmande nyckel?

Ett exempel:

Tabell Anläggning:
Ort, Telefon, Info, Dygnspris
Ort=primärnyckel

Tabell bokning:
BoknID, Hund, Ort, Starttid, Antal_dagar
BoknID=primärnyckel

Tabell hund:
HundID, Hundnamn, Ras, Info, Ägarnamn, Ägartelefon
HundId=primärnyckel

A)
Uppgiften är att få fram information om samtliga dagar en hund har varit bokad. Vi ska ha hundens namn, anläggningsort, startdatum, antal dagar och kostnad för vistelsen. Hur skriver man den selectsatsen?

B)
I nästa selectsats ska vi ha hundnamn, ägarnamn, ägartelefon, ankomstdag och antalet bokade dagar. Sedan ska det vara sorterat i ankomstordning. Hur skrivs den selectsatsen?

Dessa frågor kommer från en exempeltenta

Jag hade också varit tacksam om ni kunde förklara hur en outer join/inner join funkar i ett litet exempel.

Tack!

det du behover gora ar att anvanda join

http://www.codeproject.com/Articles/...-Tables-in-SQL

ok, om jag förstår det rätt borde A):

SELECT Hund.Hundnamn, Hund.Ägarnamn, Hund.Ägartelefon, Bokning.Starttid, Bokning.Antal_dagar
FROM Hund
INNER JOIN Bokning
ON Hund.HundID=Bokning.HundID;

Kan detta stämma?

Du glömde

order by Bokning.Starttid

För TS framtida äventyr inom databasernas förlovade värld rekommenderas tråden https://www.flashback.org/t1683261, förvisso ganska lång, men väl så nyttig då den behandlar precis denna problematik.

Nu beror detta helt på vilken databas du jobbar mot.



select c.hundnamn, a.ort, b.antal_dagar, (b.antal_dagar*a.dygnspris)
from anläggning a, bokning b, hund c
where a.ort = b.ort
and b.hund = c.hund



select c.hundnamn, c.ägarnamn, c.ägartelefon, b.startid(?), b.antal_dagar
from anläggning a, bokning b, hund c
where a.ort = b.ort
and b.hund = c.hund
order by b.starttid

Och för att min besserwisser-gen ska få lite utlopp så här på morgonkvisten, om man skriver sådan här, "gammal" sql så får man tänka på att man jobbar med en cartesisk produkt, dvs ett stort resultatset bakom kulisserna. Man kan få minnesproblem deluxe, så där är optimeringstänk viktigt, hur man skriver sql-satsen. Med bara små tabeller spelar det ingen praktisk roll dock...

Mjo förvisso sant, men det är där views, materialized views, indexering etc kommer in.

Nu var det bara ett direkt svar på hans fråga

Nu blev jag nyfiken. Finns det nyare SQL som inte ger minnesbekymmer?

Gammal SQL-join:

select *
from tabell1, tabell2, tabell3
where tabell1.col1 = tabell2.col1 and tabell2.col2 *= tabell3.col2

Ny SQL-join:
select *
from tabell1
join tabell2 on tabell1.col1 = tabell2.col1
left join tabell3 on tabell2.col2 = tabell3.col2


Skillnaden är hur databasmotorn jobbar. Med det senare exemplet skapas först ett resultatset av tabell1 och 2, som i sin tur leftjoinas mot tabell 3.

I det förstnämnda exemplet crossjoinas alla tre tabeller ihop till ett enda stort resultatset, som sedan filtreras. Det kostar mer för servern att köra den frågan helt enkelt.

Däremot finns det aldrig några garantier för att man slipper minnesbekymmer. Men det var länge sedan jag fick nåt sånt i SQL Server, så jag börjar glömma bort hur det var.

För att se vad databasen har för sig bakom kulisserna kan man ju i SQL server ta "include execution plan" och då få upp en representation av vad databasen har gjort, med rader i resultat etc så ser man det.

I mysql heter motsvarande tricks EXPLAIN. kör en sådan på de bägge fallen så lär du bli varse skillnaden. I dagens query optimizers är ju sannolikheten inte så stor att man får minnesproblem dock, det är iaf min erfarenhet.