Hur gör man för att koppla ihop ett id i en tabell med ett namn i en annan tabell.

jag har en userstabell med all info om en användare och en mailtabell där avsändare och mottagare är siffror. Om ex pelle som har id 4 har mailat mig så vill jag koppla ihop 4-an med användaren pelle i userstabellen

Om MailText ligger i mailtabellen och förnamn och efternamn ligger i User-tabellen så kan det se ut så här:

SELECT MailText, Förnamn + ', ' + EfterNamn AS Namn FROM Mail
JOIN User ON Mail.Id = User.Id
WHERE Mail.Id = 4

Mvh, Janne

hur ska jag då skriva om sender och reciever (som är tal) ligger i tblUsers_imail ska kopplas med username (som är text) lliger i tblUsers

Räknaren för tblUsers_imail är ID och i tblUSers är räknaren userID

så
sender --> username
reciever --> username

Nu är jag ute på hal is. Andreas H kommer säkert med en smartare lösning :-) Man borde kunna joina in tblUsers två gånger. En för sender och en för reciever. Id för reciever måste du ju förstås ha innan du ställer frågan.

SELECT MailText, S.Förnamn + ' ' + S.EfterNamn AS Sender, R.Förnamn + ' ' + R.EfterNamn AS Reciever
FROM tblUsers_imail U
LEFT JOIN tblUsers S ON U.Id = S.Id
LEFT JOIN tblUsers R ON U.Id = R.Id
WHERE U.Id = 4

Mvh, Janne

Den var nästan precis som den skulle...
INNER JOIN skulle vara bättre än en LEFT JOIN. Det är det enda :)

Med undantag av att man behöver faktiskt ingen WHERE - då får man en lista över alla (kommunicerande par)

/micke

INNER JOIN / LEFT JOIN saka samma. Själv förerar jag LEFT JOIN. Men det är inget "fel" att använda INNER JOIN. Jag förutsätter att det finns referens integritet i databasen, vilket innebär att alla "nummer" i mottagar och avsändar kolumnerna motsvarar en poster i användar tabellen.

Då man visar t.ex. en inkorg brukar man inte ha behov av at slå upp mottagaren. Då denna redan är känd. T.Ex.
<code>
lngUserId = CLng(Session("UserId"))

strSQL = "SELECT Mail.*, User.UserName AS SenderName" & vbCrLf & _
"FROM Mail LEFT JOIN User ON Mail.MailSender = User.UserId" & vbCrLf & _
"WHERE Mail.MailReciver = " & lngUserId
</code>
Eller utkorgen:
<code>
lngUserId = CLng(Session("UserId"))

strSQL = "SELECT Mail.*, User.UserName AS SenderName" & vbCrLf & _
"FROM Mail LEFT JOIN User ON Mail.MailReciver = User.USerId" & vbCrLf & _
"WHERE Mail.MailSender = " & lngUserId
</code>

> INNER JOIN / LEFT JOIN saka samma

Nej, det är det inte. En inner join är snabbare än en outer join i vissa fall.

Det kan vara dig som författaren talar om här...

"If you have a query that use a LEFT OUTER JOIN, check it carefully to be sure that is the type of join you really want to use. As you may know, a LEFT OUTER JOIN is used to create a result set that includes all of the rows from the left table specified in the clause, not just the ones in which the joined columns match. In addition, when a row in the left table has no matching rows in the right table, the result set row contains NULL values for all the selected columns coming from the right table. If this is what you want, then use this type of join.

The problem is that in the real world, a LEFT OUTER JOIN is rarely needed, and many developers use them by mistake. While you may end up with the data you want, you may also end up with more than the data you want, which contributes to unnecessary overhead and poor performance. Because of this, always closely examine why you are using a LEFT OUTER JOIN in your queries, and only use them if they are exactly what you need. Otherwise, use a JOIN that is more appropriate to your needs. [6.5, 7.0, 2000] Added 3-27-2002"

http://www.sql-server-performance.com/tuning_joins.asp

Har du läst texten du bifogade?

Jag anser den ej tillämpbar. Detta för at jag förutsätter att referens integritet upprätthålls med hjälp av Constranits.

Din text är bara tillämpbar om avsändare och/eller motagare skuloe var null. Finns det någon anledning för dem att vara det? Mittt svar är nej.

Därför förutsätter jag att en Left Join kommer ge samma resultat som en Inner Join.

Jag ifrågasätter inte artikeln. MEn jag se väldigt få tillfällen då den är tillämpbar. Detta anser jag inte var ett av fallen. Du är välkommen att ifrågasätta mig. Ser fram emot det. ;o)

Tror du att jag skulle bifoga texten om jag inte läst den?

Det normala sättet att joina ihop två tabeller är med en inner join. Jag ser ingen anledning att använda en outer join när man kan använda en inner join.

Du säger däremot att du föredrar en outer join (left outer join) framför en inner join. Varför?

Ifall du regelmässigt använder outer join istället för inner join utan att fundera på varför, så är det precis dig som författaren till texten talar om.

Av följande anledningar:
* Jag utgår alltid från data. Att få uta alla data som är relvant brukar även inkuldera föräldralös data.
* Min logick(kanske helt felaktigt) säger mig att en Left jon borde var effektivare eftersom den slipper kontroller bägge tabeller. Tror inte detta har så stor betydles då det är vanligt att man använder index. Men jag gissar att Left är effektivare en än inner jon om resultatet är identisk. Större skillnad ju fler tabeller man använder eftersom en Iner join är tvungen att arbeta mot resultat av olka joins medans en left borde databas motorn kunna optimera bättre.
* Gör en fråga mer läsbar.

En inner join är effektivare, då SQL kan välja vilken ordning den läser tabellerna. Om du säger att den skall returnera hela den ena tabellen, men bara delar av den andra, så har du effektivt gjort att den inte använder ett index på "den vänstra" tabellen. Gör du en inner join kan SQL välja vilken av tabellerna den skall börja med, och detta är alltså effektivare.
Dessutom anser jag att man ALLTID bara skall fråga efter det data man behöver.

Exempel, så jag slipper bli flamad:

Du vill se dina kunder och deras ordrar. Jag gör en INNER JOIN.
Om du förutom att se kunder och deras ordrar också vill se alla kunder som inte har ordrar, och se det på samma gång i samma resultat, så skall du ju självklart använda en LEFT join. Men vill du se dina kunder och deras ordrar, så...

Nu var frågan hur man ser sändare OCH mottagare - inte hur man ser sändare som inte har mottagare eller tvärt om. Då är det dessutom principiellt fel att fråga efter en left join, för det var inte det som söktes.

/micke

Hej Andreas

Problemet med den join jag vill ha är att jag får typblandningsfel och så även i detta fall.

lngUserId = CLng(Session("UserId"))

Set read=objConn.Execute("SELECT tblUsers_imail.*, tblUsers.username AS SenderName" & vbCrLf & _
"FROM tblUsers_imail LEFT JOIN tblUsers ON tblUsers_imail.sender = tblUsers.userid" & vbCrLf & _
"WHERE tblUsers_imail.reciver = " & lngUserId)

När man skickar ett mail så har en avsändare alltid en mottagare så här behöver man inte oroa sig för att man skickar ett mail till nån som inte är mottagare

Detta beror troligen på att du använder olika fälttyper i dina tabeller. Var vänlig kontroller att kolumnerna tblUsers_imail.sender och tblUsers.userid har samma datatyper och storlek.

Om detta inte löser dina problem ber jag dig bifoga en beskrivninhg av datastrukturen för bägge tabellerna.

Det är nog lättare för mig om jag ger ett konkret exempel:

Låt oss säga att vi har ett order system. Jag vill, för användarvänlighetens skull, göra det möjligt att spara en order utan att angiven en kund(OrderKund = Null). Detta för att användaren, som kanske redan påbörjat skriva sin order, skall slippa en popup/messagebox så påpekar användare att denna inte angivit någon kund. Vilket vanligtvis tvingar användaren att helt enkelt ta bort ordern, lägga till kunden, för att sedan skapa ordern igen.

Vi har ni möjlighet till härrelösa poster.

Användaren har en lista där de kan se sina ordrar. Användaren får med en LEFT JOIN öven upp det ordrar vilket har null i fältet OrderKund. Användaren kan därför öppna upp en sin order och ange vilken kund. Nu när användaren har haft möjlighet efter t.ex. en fika att fråga en kollega. Användaren markerar sedan ordern för vidare behandling.

I detta senario är inte INNER JOIN's aktuellt. Håller du med mig. Dett är just detta tänkande jag eftersträva att föravidare då jag anser detta var en mycket mer användarvänlig synvinkel.

Du är gärna välkommen med synpunkter eller om du vill att jag förtydligar något.

/Mvh, Andreas Hillqvist - Erfaren programmerare som tror sig vet vad användaren vill ha, men kan ha fullständigt fel. ;o)

sender och reciever är av typen tal och userID är räknare och primärnyckel

Jag utgår att det finns en "räknare" i User med namnet UserId vilkets tal motsvarar användarna i kolumnerna Mail.MailSender och Mail.MailReciver. Kan det vara så att du har angivit ett annat fältnamn för din räknar. T.Ex. User.ID.

JAg använder min egen namnstandrd i mina exemplel. För at frågan skall få en tydlig överblick. Namngivningen i din datastruktr kanske skiljer sig från min. Du bör därför kontrolera mina fältnamn mot dina för att hitta "rätt" fällt.

Om något är otydligt ber jag dig ställa fråger så att jag kan förklar ytterligare.

Detta innebär ju att din referensintegritet inte funkar!
Vad händer om man inte anger nån kund alls? då har man ju en order som inte kan skickas. Din tanke är bisarr! Vem lägger ordern? Är det inte en kund? Eller menar du att dina användare sitter och lägger ordrar slumpmässigt, sedan frågar de: Hallå, jag har en order, finns det någon kund som vill ha den?
Ge dig! Det finns (ett fåtal) fall där LEFT JOIN är relevant, men inte i något av dessa fall.

/micke

Du har associerat fritt utan att först be mig förtydliga mig.

Jag syftar med mitt exempel på ordersystem likt t.ex. SPCS. Där användaren är en anställd och matar in uppgifter genom en "rik applikation". Jag har gått från webbsidor utan att berätta det från dig.

Referensintegritet tillåter null. Anger man null betyder det att posten inte är relaterat till någon av påsterna i den andra tabellen. En mycket bra funktion.

Referensintegritet för mig innebär att inga poster har id nummer vilket saknas i den andra tabellen.

Jag har utvecklat applikationer proffisonelt under 4 års tid. Det jag försöker förmedla är det jag lärt mig av användaren. En användare vill ha frihet och inte ett program som tvingar dem arbetar efter programmerarens noter.

Du har rätt att tycka som du vill. Men jag anser diskussonen om OTER LEFT JOIN och INNER JOIN avslutad. Förutsatt att du eller någon annan har något nytta att tillföra diskussionen. Det käns för mig annars som vi kan fortsätta att kömpa för vår skiljda synpunkter och uppfattningar hur länge som helst.

/Mvh, Andreas Hilqvist - Envis som en åsna men alltid öppen att omvärdera sina åsikter då information presenteras på ett konstruktivt sätt

Min struktur för tblUsers
userID username password FullName + andra kolumner
userID är räknare och primärnyckel
username, password och FullName är text


Min struktur för tblUsers_imail

ID mailDate sender reciever message read
33 2004-05-11 1 2 fdsfdsfer 0

ID är räknare och primärnyckel , sender och reciever är text, message är pm och read är ja/nej
Här är avsändaren post 1 i tblUsers och mottagaren är post nummer 2

Lösning för latmasker... ;o)

Inkorg:
<code>
lngUserId = CLng(Session("UserId"))

strSQL = "SELECT tblUsers_imail.*, UserSender.UserName AS SenderName, UserSender.UserFullName AS SenderFullName" & vbCrLf & _
"FROM tblUsers_imail LEFT JOIN tblUsers AS UserSender ON tblUsers_imail.Sender = UserSender.UserId" & vbCrLf & _
"WHERE tblUsers_imail.Reciver = " & lngUserId
</code>


Utkorgen:
<code>
lngUserId = CLng(Session("UserId"))

strSQL = "SELECT tblUsers_imail.*, UserReciever.UserName AS ReciverName, UserReciever.UserFullName AS ReciverFullName" & vbCrLf & _
"FROM tblUsers_imail LEFT JOIN tblUsers AS UserReciever ON tblUsers_imail.Reciver = UserSender.UserId" & vbCrLf & _
"WHERE tblUsers_imail.Sender = " & lngUserId
</code>

Jag hoppas dess fråger fungera felfritt. JAg reserverar mig för stavfel osv... Är ju långt från perfekt. Bar duktig och hjälpsam. ;o)

/Mvh, Andreas Hillqvist - Bara mänsklig

Set read=objConn.Execute("SELECT tblUsers_imail.*, tblUsers.username AS SenderName, tblUsers.FullName AS SenderFullName" & vbCrLf & _
"FROM tblUsers_imail LEFT JOIN tblUsers AS UserSender ON tblUsers_imail.sender = tblUsers_imail.userID" & vbCrLf & _
"WHERE tblUsers_imail.Reciever = " & lnguserId)

Kopplingsuttrycket stöds inte får jag med den här

<Där användaren är en anställd och matar in uppgifter genom en "rik applikation".

Vill man fortfarande inte veta vem som "äger" en order, det är alltså en föräldralös post.

<Referensintegritet tillåter null

Men vad är NULL? Är det saknas, vet inte, kan inte eller får inte. Introducerar man null, så får man 6-värd logik. man har true/false/nullx4. Null är OND!

<Jag har utvecklat applikationer proffisonelt under 4 års tid.

10...

<En användare vill ha frihet

En användare vill också ha lösenordet till sa - och massa andra korkade saker.

<Men jag anser diskussonen om OTER LEFT JOIN och INNER JOIN avslutad.

Visa mig ETT exempel där det gynnar användare eller databas att ha en order (eller något annat) utan relaterad kundinformation.

Jag säger inte att det är fel med outer join, jag säger att det är fel att alltid använda det.
Provkör gärna dessa 2 i Query analyser (SQL Server) och jämför planerna. Resultaten är identiska, men med en OUTER JOIN har du tvingat fram en något sämre plan för SQL
<code>
set statistics io on
use Northwind
GO
select productname, unitprice, categoryname
from categories inner join products
on categories.categoryid = products.categoryid

select productname, unitprice, categoryname
from categories left outer join products
on categories.categoryid = products.categoryid
</code>
Är detta tillräckligt konstruktivt?

/micke

<code>
Dim SQL as String

SQL = "SELECT im.*, S.username AS SenderName, S.FullName AS SenderFullName"
SQL = SQL & " FROM (tblUsers_imail im INNER JOIN tblUsers S ON im.sender = S.userID)"
SQL = SQL & " WHERE im.Reciever = " & lnguserId

Set read=objConn.Execute(SQL)

</code>

/micke

fortfarande typblandningsfel, blir snart galen på det här :-)

Du får typblandningsfel/kopplingsinstruktionen stöds ej om vartannat. Vilket är det?

En räknare motsvarar Långt Heltal, har du inte det så får du ändra i din imail tabell. Det är nog det som är problemet, du hade <e>Text</e>, som inte är samma datatyp.

*Ändrat... såg inte din tabellspec innan - sorry...

/micke

Anledningen till typblandningsfelet är att du jämför ett fält av typen tal med ett fält av typen text.

Ändra sender och reciever till tal i databasen.

"Ändra sender och reciever till tal i databasen."

Det är pecis det jag har och jag får typblandningsfel, om du kollar i min tabellspec så ser du siffror och inte text

<citat>
Min struktur för tblUsers_imail

ID mailDate sender reciever message read
33 2004-05-11 1 2 fdsfdsfer 0

ID är räknare och primärnyckel , sender och reciever är text, message är pm och read är ja/nej
Här är avsändaren post 1 i tblUsers och mottagaren är post nummer 2
</citat>

Notera speciellt meningen som säger "sender och reciever är text". Näst sista raden i citatet.
Det hjälper inte att det är siffror, du måste ha datatypen Långt Heltal också

/micke

jag använder just nu

lnguserId = CLng(Session("UID"))

SQL = "SELECT im.*, S.username AS SenderName, S.FullName AS SenderFullName"
SQL = SQL & " FROM (tblUsers_imail im INNER JOIN tblUsers S ON im.sender = S.userID)"
SQL = SQL & " WHERE im.Reciever = " & lnguserId

Set read=objConn.Execute(SQL)

och när jag klickar på en av länkarna för att läsa just det mailet så visas bara första posten och med ex <%=read("sender")%> så får jag inte fram något namn på vem mailet är från

> * Jag utgår alltid från data. Att få uta alla data som är relvant brukar även inkuldera föräldralös data.

Bara ifall du vill ha ut all data ur huvudtabellen. Så fort du vill begränsa antalet poster genom att lägga ett villkor på ett värde från en tabell du joinar in, så måste du använda en inner join.

> * Min logick(kanske helt felaktigt) säger mig att en Left jon borde var effektivare eftersom den slipper kontroller bägge tabeller. Tror inte detta har så stor betydles då det är vanligt att man använder index. Men jag gissar att Left är effektivare en än inner jon om resultatet är identisk. Större skillnad ju fler tabeller man använder eftersom en Iner join är tvungen att arbeta mot resultat av olka joins medans en left borde databas motorn kunna optimera bättre.

Jo, logiken är tyvärr felaktig. Villkoret för att joina ihop tabellerna bestämmer ju vilka poster i den första tabellen som ska paras ihop med vilka poster i den andra tabellen. Alla poster måste matchas mot varandra oavsett vilken typ av join det är.

> * Gör en fråga mer läsbar.

Varför skulle en fråga bli mer läsbar av en outer join än en inner join?

Snarare gör det frågan svårare att läsa. En inner join är som sagt det normala sättet att joina ihop två tabeller. Ifall man använder en outer join så indikerar man att det är något speciellt med relationen mellan tabellerna, att det inte är ett vanligt ett-till-ett eller ett-till-många-förhållande mellan tabellerna.

> Det är pecis det jag har och jag får typblandningsfel, om du kollar i min tabellspec så ser du siffror och inte text

Jag kanske var lite otydlig... Det är datatypen på fälten som du ska ändra till tal.

Bara för att fältet innehåller siffror så är det inte ett tal. Ifall datatypen är text så är värdet i fältet text, oavsett om det innehåller bokstäver eller siffror.

Det borde väl vara

<%=read("SenderFullName")%>


>länkarna för att läsa just det mailet så visas bara första posten
Finns det fler än en post?
Det du får ut i frågan är ALLA mail som har lnguserId som mottagare. Då borde du få fler poster (länkarna kanske) sedan när du klickar på länken, så ville du läsa ett mail. Då bör du ju bara se en post, eftersom det är en länk du klickar på.
har jag missupfattat så får du utveckla dig rejält. Vad vill du göra?

/micke

Nu fungerar avsändarnamnen som de ska, men om första mailposten för det aktuella kontot är 30 och sista 45 och man klickar på mail 35 så visas nr 30, dvs det första.....oavsett vilket mail man klickar på så är det samma....man vill ju läsa det mail man klickar på :-)

Vad skickar du med för information i länken?

Ifall du vill visa ett specifikt meddelande så är det lämpligt att skicka med id för just den posten.

skickar med
<a class="menu" href="?read=mail&ID=<%=read("userID")%>"><%=LEFT(read("message"),35)%> ....</a>

Ser att ID-numren stämmer i listan över inkomna mail.....men klickar jag på ID 35 så vill jag läsa just den posten och inte ID 30 som är första

Du skickar med användarens id, inte meddelandets id.

Av den informationen så kan du bara hämta ut alla meddelanden som en användare skickat eller tagit emot, inte ett specifikt meddelande.

Du måste skicka med meddelandets id istället, och sedan använda det i databasfrågan för att plocka ut det specifika meddelandet, istället för alla meddelanden för en person. När du hämtar alla meddelanden för en person, men bara visar ett meddelande, så visas ju det meddelande som kommer först.

<code>
'På samma sätt som du matar in lnguserId måste du mata in
'lngMSGId i en variabel. Du skickar med det. Bra. Men du
'måste mata in det i frågan också.

SQL = "SELECT im.*, S.username AS SenderName, S.FullName AS SenderFullName"
SQL = SQL & " FROM (tblUsers_imail im INNER JOIN tblUsers S ON im.sender = S.userID)"
SQL = SQL & " WHERE im.Reciever = " & lnguserId
SQL = SQL & " AND im.ID = " & lngMSGId

'Egentligen är kontrollen på Reciever onödig, MEN det skadar inte.
'Det KAN bli bättre prestanda och man löper inte någon risk
'att en User ser någon annans mail.

Set read=objConn.Execute(SQL)
</code>

/micke

förtår inte det där med im, kan du förklara koden så att jag vet exakt vad den gör :-) , och tack för all hjälp

hur ska man få lngMSGId att funka?

>>Där användaren är en anställd och matar in uppgifter genom en "rik applikation".
>>
>Vill man fortfarande inte veta vem som "äger" en order, det är alltså en föräldralös post.
>
Om ordern utan kund fungerar som mall behöver då ha kund referens? Svar Nej.
Genom att då använda null i kunden för mallar, slipper du skapa en mall post i kundtabell eller en hel kopia av orderstrukturen för mallar. Är inte detta ett mycket användbart exempel?


>>Referensintegritet tillåter null
>>
>Men vad är NULL? Är det saknas, vet inte, kan inte eller får inte. Introducerar man null, så får man 6-värd logik. man har true/false/nullx4. Null är OND!
>
Det är din åsikt. Null innebär avsaknad av värde. Vilket passr just för referensintegritet där relationer inte är nödvändiga. ÄR det jag som har fel på minna matte kunskaper men jag kan bara räkna true/false/null till tre. :oP

>>Jag har utvecklat applikationer proffisonelt under 4 års tid.
>>
>10...
>
Fast vad spelar ålder för roll. *Visslar oskyldig* ;o)

>>En användare vill ha frihet
>>
>En användare vill också ha lösenordet till sa - och massa andra korkade saker.
>
Varför ens använda SA konto när SQL server stödjer NT konton.

Tala om för användare att de utgör en säkerhetsrisk. Att dra alla användares åsikter som dumheter anser jag var fel. Användaren är de som kommer använda systemet inte du. De har rätt att kräva att programmet skall vara lätta att arbeta med. Menar du att du alltid vet bättre än användaren hur de kommer använda systemet?

>>Men jag anser diskussonen om OTER LEFT JOIN och INNER JOIN avslutad.
>>
>Visa mig ETT exempel där det gynnar användare eller databas att ha en order (eller något annat) utan relaterad kundinformation.
>
Har gjort det. Se ovan. ;o)

>Jag säger inte att det är fel med outer join, jag säger att det är fel att alltid använda det.
>Provkör gärna dessa 2 i Query analyser (SQL Server) och jämför planerna.
>Resultaten är identiska, men med en OUTER JOIN har du tvingat fram en något sämre plan för SQL
>

Har tyvärr inte SQL server. Var vänlig att publiera dit resultat. Använd mer än et exempel och flera olika tabelle strukturer. Med två till flera tabeller.

JAg drar inte slutsatser av ett enskilt test. Det ger ingen stabil grund för slusatser. Men jag tvivlar inte på att du har rätt. Vill bara ha konkreta bevis för att acceptera det.

Annars hade jag varit religös fanatiker, om jag trot på allt prästen säger.

>> * Jag utgår alltid från data. Att få uta alla data som är relvant brukar även inkuldera föräldralös data.
>>
>Bara ifall du vill ha ut all data ur huvudtabellen. Så fort du vill begränsa antalet poster genom att lägga ett villkor på ett värde från en tabell du joinar in, så måste du använda en inner join.
>
JAg kan hålla med dig om det är så att vilkoren gäller fält i den joinade tabellen.

T.Ex. :

SELECT User.*
FROM User INNER JOIN GroupMembers ON User.UserID = GroupMembers.UserID
WHERE GroupMembers.GroupID = 1543

Detta skulle jag översätta till följande LEFT JOIN fråga:

SELECT User.*
FROM GroupMembers LEFT JOIN User ON GroupMembers.UserID = User.UserID
WHERE GroupMembers.GroupID = 1543

Just för att vilkoret begränsar urvalet i GroupMembers. De användare som sedan är relevanta slås upp.

Men då vilkoret/vilkore bara gäller fält i huvudtabellen och Join'en bara slår information som inte filtreras, kan jag inte hålla med.

SELECT Kunder.*, Orter.OrtNamn
FROM Kunder INNER JOIN Orter ON Kunder.PostNr = Orter.PostNr
WHERE Kunder.PostNr = 42248

VS

SELECT Kunder.*, Orter.OrtNamn
FROM Kunder INNER JOIN Orter ON Kunder.PostNr = Orter.PostNr
WHERE Orter.PostNr = 42248

VS

SELECT Kunder.*, Orter.OrtNamn
FROM Kunder LEFT JOIN Orter ON Kunder.PostNr = Orter.PostNr
WHERE Kunder.PostNr = 42248

VS

SELECT Kunder.*, Orter.OrtNamn
FROM Orter LEFT JOIN Kunder ON Orter.PostNr = Kunder.PostNr
WHERE Orter.PostNr = 42248

Frågerna bör ge samma resultat. Men vilka fråger är effektivast, lättlästa osv...

>> * Min logick(kanske helt felaktigt) säger mig att en Left jon borde var effektivare eftersom den slipper kontroller bägge tabeller. Tror inte detta har så stor betydles då det är vanligt att man använder index. Men jag gissar att Left är effektivare en än inner jon om resultatet är identisk. Större skillnad ju fler tabeller man använder eftersom en Iner join är tvungen att arbeta mot resultat av olka joins medans en left borde databas motorn kunna optimera bättre.
>>
>Jo, logiken är tyvärr felaktig. Villkoret för att joina ihop tabellerna bestämmer ju vilka poster i den första tabellen som ska paras ihop med vilka poster i den andra tabellen. Alla poster måste matchas mot varandra oavsett vilken typ av join det är.
>
Var vänlig bifoga informatuionen du grundar ditt utalande på så att jag kan bekräfta den. Om du påstår att något garanterat är på et sätt. Bör du kunna backa upp det med en specifikatione ller liknade. Annars finns det risk att jag tvivlar eller inte tar till mig den. Vart fick du tag i informationen?

>> * Gör en fråga mer läsbar.
>>
>Varför skulle en fråga bli mer läsbar av en outer join än en inner join?
>
Du har inte sett mina databas diagram. Utgår alltid från vänster till höger. Därför blir det många LEFT relationer. ;o)

>>> * Min logick(kanske helt felaktigt) säger mig att en Left jon borde var effektivare eftersom den slipper kontroller bägge tabeller. Tror inte detta har så stor betydles då det är vanligt att man använder index. Men jag gissar att Left är effektivare en än inner jon om resultatet är identisk. Större skillnad ju fler tabeller man använder eftersom en Iner join är tvungen att arbeta mot resultat av olka joins medans en left borde databas motorn kunna optimera bättre.
>>>
>> Jo, logiken är tyvärr felaktig. Villkoret för att joina ihop tabellerna bestämmer ju vilka poster i den första tabellen som ska paras ihop med vilka poster i den andra tabellen. Alla poster måste matchas mot varandra oavsett vilken typ av join det är.
>>
> Var vänlig bifoga informatuionen du grundar ditt utalande på så att jag kan bekräfta den. Om du påstår att något garanterat är på et sätt. Bör du kunna backa upp det med en specifikatione ller liknade. Annars finns det risk att jag tvivlar eller inte tar till mig den. Vart fick du tag i informationen?

Var jag fick tag på informationen? Det minns jag inte, det var när jag lärde mig hur man använder relationsdatabaser för ungefär 15 år sedan...

Det handlar om vad som händer när du joinar ihop två tabeller. Tänk dig att du har dessa två tabeller:

Tabell1 (id)
1
2
3

Tabell2 (id)
1
2
3

Ifall du kör frågan "select Tabell1.id, Tabell2.id where Tabell1.id=Tabell2.id" så är det detta som händer (teoretiskt sett):

Ett arbetsresultat skapas där varje post i den ena tabellen paras ihop med varje post i den andra tabellen, alltså resultatet av "select Tabell1.id, Tabell2.id":

Arbetsresultat (Tabell1.id, Tabell2.id)
1, 1
1, 2
1, 3
2, 1
2, 2
2, 3
3, 1
3, 2
3, 3

Sedan filtreras de poster bort där villkoret inte är sant:

Arbetsresultat (Tabell1.id, Tabell2.id)
1, 1
1, 2 <--- bort
1, 3 <--- bort
2, 1 <--- bort
2, 2
2, 3 <--- bort
3, 1 <--- bort
3, 2 <--- bort
3, 3

Det slutliga resultatet:
1, 1
2, 2
3, 3

Värdena från alla poster i bägge tabellerna måste alltså användas för att avgöra vilka poster som ska filtreras bort.

<Om ordern utan kund fungerar som mall behöver då ha kund referens? Svar Nej.
<Genom att då använda null i kunden för mallar, slipper du skapa en mall post i kundtabell eller en hel <kopia av orderstrukturen för mallar. Är inte detta ett mycket användbart exempel?

Du har inte hört talas om at en tabell innehåller EN sak. T.ex. ordrar (orders) mallar (templates)
Gör du tabeller som innehåller kunder - och anställda, men bara om kundnummer är null?. Det strider mot andra normaliseringsregeln att lagra mer än en sak i en tabell. En mall skall lagras där mallar skall lagras.


<Det är din åsikt. Null innebär avsaknad av värde. Vilket passr just för referensintegritet där relationer <inte är nödvändiga. ÄR det jag som har fel på minna matte kunskaper men jag kan bara räkna <true/false/null till tre. :oP

Varför saknas värdet? Är det för att du inte kan mata in det? Är det för att det inte är tillämpbart, eller är det för att du inte vet vad det skall vara. Det var tre exempel - olika - som alla representeras med null.


<Användaren är de som kommer använda systemet inte du. De har rätt att kräva att programmet skall <vara lätta att arbeta med. Menar du att du alltid vet bättre än användaren hur de kommer använda <systemet?

Nej, men jag vet hur de inte bör använda systemet.


<Har tyvärr inte SQL server. Var vänlig att publiera dit resultat. Använd mer än et exempel och flera <olika tabelle strukturer. Med två till flera tabeller.

OK.

SELECT ProductID, ProductName, CategoryName
FROM Categories INNER JOIN Products
ON Categories.CategoryID = Products.CategoryID

Denna gör precis som den skall. Den optimerar antalet läsningar från tabellerna.

*********************
(77 row(s) affected)

Table 'Categories'. Scan count 77, logical reads 154, physical reads 0, read-ahead reads 0.
Table 'Products'. Scan count 1, logical reads 2, physical reads 0, read-ahead reads 0.

Den läser igenom tabellen Products en gång. För varje rad i Products gör den en sökning i tabellen
Categories och returnerar CategoryName.
Om jag "vänder" på frågan får jag exakt samma resultat, då det är det smartaste sättet att göra.

SELECT ProductID, ProductName, CategoryName
FROM Categories LEFT OUTER JOIN Products
ON Categories.CategoryID = Products.CategoryID

Här har jag sagt att jag måste ha alla kategorier - även de kategorier som inte har produkter i sig.
Varför finns det tomma kategorier, ja, det vet jag inte men det finns. OK så långt är det bra.
MEN VARFÖR envisas jag med att matcha ihop alla produkter som har en kategori med sin respektive kategori?
Det blir egentligen som att ha 2 resultat i samma resultat:
1. Alla produkter, med sin kategori
2. Alla kategorier som inte har en produkt

******************
(77 row(s) affected)

Table 'Products'. Scan count 8, logical reads 162, physical reads 0, read-ahead reads 0.
Table 'Categories'. Scan count 1, logical reads 1, physical reads 0, read-ahead reads 0.

Vi tvingar fram en scan av tabellen Categories, eftersom vi vill ha alla rader i den.
Som du ser är inte det lika bra som en inner join.
Tänker man till nu, så kanske man vill vända på frågan (skriva en right outer join). och
då får man samma plan som vid en inner join, med undantaget att man nu får alla produkter,
även de som inte har någon kategori.


*******************************************************************
Slut på exempel 1
*******************************************************************

SELECT CompanyName, OrderDate, ProductID, UnitPrice
FROM Customers INNER JOIN Orders
ON Customers.CustomerID = Orders.CustomerID
INNER JOIN [Order Details]
ON Orders.OrderID = [Order Details].OrderID

Table 'Order Details'. Scan count 830, logical reads 1672, physical reads 0, read-ahead reads 0.
Table 'Orders'. Scan count 1, logical reads 21, physical reads 0, read-ahead reads 0.
Table 'Customers'. Scan count 1, logical reads 1, physical reads 0, read-ahead reads 0.

Talar för sig själv...

Nu är problemet VILKEN/VILKA av alla tabeller som är "LEFT" Det hoppas jag att du noggrannt
tänkt igenom, i och med att du får olika resultat beroende på vad du väljer...
För tydlighets skull kommer jag köra alla kombinationer och visa resultaten.

1
-----------------------------------------------------
SELECT CompanyName, OrderDate, ProductID, UnitPrice
FROM Customers LEFT OUTER JOIN Orders
ON Customers.CustomerID = Orders.CustomerID
INNER JOIN [Order Details]
ON Orders.OrderID = [Order Details].OrderID

Table 'Order Details'. Scan count 830, logical reads 1672, physical reads 0, read-ahead reads 0.
Table 'Orders'. Scan count 1, logical reads 21, physical reads 0, read-ahead reads 0.
Table 'Customers'. Scan count 1, logical reads 1, physical reads 0, read-ahead reads 0.

2
-------------------------------------------------------
SELECT CompanyName, OrderDate, ProductID, UnitPrice
FROM Customers LEFT OUTER JOIN Orders
ON Customers.CustomerID = Orders.CustomerID
LEFT OUTER JOIN [Order Details]
ON Orders.OrderID = [Order Details].OrderID

Table 'Order Details'. Scan count 830, logical reads 1672, physical reads 0, read-ahead reads 0.
Table 'Orders'. Scan count 91, logical reads 1918, physical reads 0, read-ahead reads 0.
Table 'Customers'. Scan count 1, logical reads 1, physical reads 0, read-ahead reads 0.

3
-------------------------------------------------------
SELECT CompanyName, OrderDate, ProductID, UnitPrice
FROM Customers INNER JOIN Orders
ON Customers.CustomerID = Orders.CustomerID
LEFT OUTER JOIN [Order Details]
ON Orders.OrderID = [Order Details].OrderID

Table 'Order Details'. Scan count 830, logical reads 1672, physical reads 0, read-ahead reads 0.
Table 'Customers'. Scan count 830, logical reads 1680, physical reads 0, read-ahead reads 0.
Table 'Orders'. Scan count 1, logical reads 21, physical reads 0, read-ahead reads 0.

4 Här "vänder" vi på selectsatsen igen
och får samma resultat som originalfrågan
------------------------------------------------------
SELECT CompanyName, OrderDate, ProductID, UnitPrice
FROM [Order Details] INNER JOIN Orders
ON [Order Details].OrderID = Orders.OrderID
INNER JOIN Customers ON Orders.CustomerID = Customers.CustomerID

Table 'Order Details'. Scan count 830, logical reads 1672, physical reads 0, read-ahead reads 0.
Table 'Orders'. Scan count 1, logical reads 21, physical reads 0, read-ahead reads 0.
Table 'Customers'. Scan count 1, logical reads 1, physical reads 0, read-ahead reads 0.

5
----------------------------------------------------------
SELECT CompanyName, OrderDate, ProductID, UnitPrice
FROM [Order Details] LEFT OUTER JOIN Orders
ON [Order Details].OrderID = Orders.OrderID
INNER JOIN Customers ON Orders.CustomerID = Customers.CustomerID

Table 'Order Details'. Scan count 830, logical reads 1672, physical reads 0, read-ahead reads 0.
Table 'Orders'. Scan count 1, logical reads 21, physical reads 0, read-ahead reads 0.
Table 'Customers'. Scan count 1, logical reads 1, physical reads 0, read-ahead reads 0.



6
----------------------------------------------------------
SELECT CompanyName, OrderDate, ProductID, UnitPrice
FROM [Order Details] LEFT OUTER JOIN Orders
ON [Order Details].OrderID = Orders.OrderID
LEFT OUTER JOIN Customers ON Orders.CustomerID = Customers.CustomerID

Table 'Order Details'. Scan count 1, logical reads 10, physical reads 0, read-ahead reads 0.
Table 'Orders'. Scan count 1, logical reads 21, physical reads 0, read-ahead reads 0.
Table 'Customers'. Scan count 1, logical reads 1, physical reads 0, read-ahead reads 0.

Detta resultat kräver en extra förklaring, då det inte ser ut som de andra:
Här finns det INGET vettigt att göra. Optimizern väljer då att läsa varje tabell endast
en gång, och sedan göra en s.k. hash match. Principen bakom den är att SQL räknar ut en checksumma
på varje rad (tungt bara det) och sedan parar den ihop rader med samma checksumma. (i RAM) Här måste den
alltså ha hela resultatet i minnet innan den kan returnera något. Minnet som kunde användas till
bättre saker (cachad data t.ex.)


7
-----------------------------------------------------------
SELECT CompanyName, OrderDate, ProductID, UnitPrice
FROM [Order Details] INNER JOIN Orders
ON [Order Details].OrderID = Orders.OrderID
LEFT OUTER JOIN Customers ON Orders.CustomerID = Customers.CustomerID

Table 'Order Details'. Scan count 830, logical reads 1672, physical reads 0, read-ahead reads 0.
Table 'Orders'. Scan count 1, logical reads 21, physical reads 0, read-ahead reads 0.
Table 'Customers'. Scan count 1, logical reads 1, physical reads 0, read-ahead reads 0.


Nu har jag inte provat med FULL OUTER JOIN, som tar med alla poster från båda inblandade tabeller
eftersom du inte tagit upp att du använder det. Du kanske skall börja med det, eftersom det är (om möjligt)
ännu sämre ur prestandasynpunkt än LEFT/RIGHT JOIN. :)
Jag kunde inte motstå att läsa din profil och höll på att skratta ihjäl mig. "besserwisser"! Jodå, det är skönt att du vet det :)
men det skulle inte skada att lyssna på andra. Vi är nu 2 st som informerat dig om brister i ditt resonemang.
Innan du besserwissrar nästa gång skulle jag rekommendera att du kontrollerar fakta först.
Risken är annars uppenbar att du misstar dig - och tar strid för något som (igen) är felaktigt.

(Undrar du vad jag jobbar med? Jag har de 6 senaste åren till största delen optimerat SQL-frågor...)

/micke

Om du lärde dig relationsdatabaser för 15år sedan bör du kanske betrakta att du kanske glömt en del och utvecklingen stannar aldrig.

Ditt exempel är svårt att förstå, då det flesta databaser använder index för att just slippa dessa table-scans.

En constrain kan beskrivas som ett villkor vilket liknar ett index, men kan även användas för att upprätta relationer till andra tabeller.

SQL-syntaxen i access för en "Foreign Key Constraint" är:

CONSTRAINT NamnPåMinConstraint FOREIGN KEY [NO INDEX] (FörstFältet[, AndraFältet [, ...]]) REFERENCES SekundärTabell [(sekundärfält1 [,sekundärfält2 [, ...]])]
[ON UPDATE CASCADE | SET NULL]
[ON DELETE CASCADE | SET NULL]

Jag chansar på att en konstrain är en form av clustrat index

Exempel dax:

Types
+--------+----------+
| TypeId | TypeName |
+--------+----------+
| 1 | Amatör |
| 2 | Profss |
+--------+----------+


Users
+--------+----------+----------+
| UserId | UserType | UserName |
+--------+----------+----------+
| 1 | 2 | Andreas |
| 2 | 1 | Bengt |
| 3 | 2 | Carl |
| 4 | 1 | David |
| 5 | 2 | Erik |
+--------+----------+----------+

Clustrat index
+----------+--------+
| UserType | UserId |
+----------+--------+
| 1 | |
| | 2 |
| | 4 |
| 2 | |
| | 1 |
| | 3 |
| | 5 |
+----------+--------+

Detta ser jag som ett mer effektivs sätt. Då man använder index går det snabbare att ställa fråger. Men långsamare att lägga till, redigera och ta bort poster då berörda index uppdateras. Det är därför man ofta i t. ex. MS SQL Server har möjlighet att ange "Fill Factor" på ett index. För att man databasen skall slippa hålla hela indexet uppdaterat hela tiden.

>(Undrar du vad jag jobbar med? Jag har de 6 senaste åren till största delen optimerat SQL-frågor...)
>
Du skulle sagt det från början. Då kunde litat mer på vad du sa. Istället för att ifrågasätta allt.
Men jag kommer fortfarande ifråga sättta dig. Detta när jag inte förstår eller mina åsikter skiljer sig från dina.
Detta för att jag vill att du förklara för mig. Inte för att jag inte tror på dig. JAg hoppas du kan acceptera det. ;o)



>Du har inte hört talas om at en tabell innehåller EN sak. T.ex. ordrar (orders) mallar (templates)
>Gör du tabeller som innehåller kunder - och anställda, men bara om kundnummer är null?. Det strider mot andra normaliseringsregeln att lagra mer än en sak i en tabell. En mall skall lagras där mallar skall lagras.
>

Detta beror på hur man definerar "Mall". Jag ser en "mall" som en "order" som saknar kund. Eftersom jag ser en "mall" som en prder så lägger jag den i order tabellen. Eftersom "Ordern" alias "Mall" saknar kund sätter jag OrderKuns till null.

Alla har rätt att se saker på olika vis. Våran logik och definition kanske skiljer sig åt. Detta kanske beror på at du undviker Null medans jag Uppskattar null. ;o)

>>Det är din åsikt. Null innebär avsaknad av värde. Vilket passr just för referensintegritet där relationer >>inte är nödvändiga. ÄR det jag som har fel på minna matte kunskaper men jag kan bara räkna >>true/false/null till tre. :oP
>>
>Varför saknas värdet? Är det för att du inte kan mata in det? Är det för att det inte är tillämpbart, eller är det för att du inte vet vad det skall vara. Det var tre exempel - olika - som alla representeras med null.
>

Om ett fälts tillåts ha tre värden: true/false/null så kan det ha tre värden punkt slut.

Låt oss gå in i detalj på vad null kan stå för: "Är det för att du inte kan mata in det?", "Är det för att det inte är tillämpbart?" eller "Är det för att du inte vet vad det skall vara?"

Applikationen:
-------------------------
Ett beställning-/ordersystem för ett företag vilket kräver mycket hög tillförlitlighet på att data inte skall gå förlorad. För att inga ordrar skall gå förlorade, vid strömavbrott eller annat tekniskt fel(Klantig medarbetare snubblar över sladden, spiller kaffe i datorn och kortsluter den), arbetar applikationen direkt mot databasen. Detta för att ingen orderinformation skall gå förlorad.

När en kund ringer till callcentret för ordermotagning frågar telefonisten efter kundnummer. Om det rör sig om en ny kund skapas en kundpost och ett kundnummer tilldelas kunden.

Ordern kan betalas på flera olika sätt. Därför är den relaterad till betalningsmetoderna tabellen där det olika betalningsmetoderna finns: Kontant, Faktura, Kredit, osv...


Är det för att du inte kan mata in det?
--------------------------------------------
Företaget väljer att uppgradera sin applikation och märker till sin fasa att alla kombinationsrutor inte svarar. Detta beror på en bugg i programet. Företaget kommer förlora miljoner om det slutar ta emot ordrar och en ny patch kommer först nästa vecka. Att rulla tillbaks applikationen är inget alternativ. System ansvarig har tagit livet av sig. Så går det om man ser för många samurajfilmer.

Tillsvidare skriver de kundnummret i fältet anteckningar. För att i efterhand korrigera kunder.

Är det för att det inte är tillämpbart?
-----------------------------------------
En kund kan hör till ett företag. Privatpersoner hör inte till företag. Därför är inte företag tillämpbart på dem i kundregistret. Då lämnar man fältet tomt.

Är det för att du inte vet vad det skall vara?
------------------------------------------------------
Per som är ny på företaget är osäker på om han valt rätt kundnummer. Han kanske hörde fel. För att inte skicka iväg ordern till fel kund, lämnar han fältet tomt och frågar sin medarbetare Agneta.

>>Användaren är de som kommer använda systemet inte du. De har rätt att kräva att programmet skall >>vara lätta att arbeta med. Menar du att du alltid vet bättre än användaren hur de kommer använda >>systemet?
>>
>Nej, men jag vet hur de inte bör använda systemet.
>
Vett du hur det effektivast använder systemet? Det tror jag är intressantare för den som köper ditt system. Ju effektivare man kan arbeta med ditt system. Ju mindre tid måste en anställ lägga ner för att utföra ett moment i din applikation.

>>Har tyvärr inte SQL server. Var vänlig att publiera dit resultat. Använd mer än et exempel och flera >>olika tabelle strukturer. Med två till flera tabeller.

Har lite svårt att bedömma dina tester då jag inte känner till vilka index och constrains du använder. KAn du inkludera koden du använder för att skapa tabeller, index och konstrains?
Eller är det så att du använder en standarddatabas som Northwind?
Tycker du Northwind's uppbyggnad är optimal? Har du några synpunkter om den?

Annars kan vi utgå från. Finns ju även i Access. ;o)

Jag använde fråge guiden och skapade följande fråga:

SELECT Order.*, Kunder.Företagsnamn AS KundNamn, Anställda.Förnamn AS AnställdFörnamn, Anställda.Efternamn AS AnställdEfternamn, Speditörer.Företagsnamn AS SpeditörNamn
FROM Speditörer INNER JOIN (Anställda INNER JOIN (Kunder INNER JOIN [Order] ON Kunder.Kundnr = Order.Kundnr) ON Anställda.Anställningsnr = Order.Anställningsnr) ON Speditörer.Speditörsnr = Order.[Skicka med]
WHERE (((Order.Orderdatum)>#1/1/2000#))
ORDER BY Kunder.Företagsnamn;

JAg skulle skriva denna fråga som:

SELECT Order.*, Kunder.Företagsnamn AS KundNamn, Anställda.Förnamn AS AnställdFörnamn, Anställda.Efternamn AS AnställdEfternamn, Speditörer.Företagsnamn AS SpeditörNamn
FROM (([Order] LEFT OUTER JOIN Kunder ON Kunder.Kundnr = Order.Kundnr) LEFT OUTER JOIN Anställda ON Anställda.Anställningsnr = Order.Anställningsnr) LEFT OUTER JOIN Speditörer ON Speditörer.Speditörsnr = Order.[Skicka med]
WHERE (((Order.Orderdatum)>#1/1/2000#))
ORDER BY Kunder.Företagsnamn;

KAn du jämföra dessa två olika fråger och se om det är någon skillnad. Om det är någon skillnad berätta vilken som är bäst?

/Mvh, Andreas Hillqvist

P.S.
Någon borde ta och sammanställa detta inlägg till en artilke om Joins.
D.S.

> Om du lärde dig relationsdatabaser för 15år sedan bör du kanske betrakta att du kanske glömt en del och utvecklingen stannar aldrig.

Jo, visst har jag glömt en del. Jag har glömt mer om programmering än de flesta hinner lära sig... Större delen av 6502:s instruktionsuppsättning är mer eller mindre borta, såväl decimalvärden som ascii-tecken för opkoderna... Massor av anropen till Atari TOS minns jag inte längre på rak arm...

Relationsdatabaser har jag däremot inte glömt så mycket av, eftersom jag håller på med det dagligen.

> Ditt exempel är svårt att förstå, då det flesta databaser använder index för att just slippa dessa table-scans.

Oj, då... Jag som tog det så basic så att jag var rädd att du skulle bli förnärmad för det... Vad är det du menar är svårt att förstå?

Ifall man använder index eller inte spelar ingen roll, databasen måste ändå kolla alla poster i alla tabeller som man joinar ihop. Det blir en index scan istället för en table scan, men den måste fortfarande matcha alla posterna.

Även med constraints? Får väl bygga en egen databsmotor som är effektivare om alla befintliga är så ineffektiva.

Föresten undrar jag vart jag kan hitta information om hur joins fungerar under huven? Vart har du fått din information? Källgranskning är viktigt i informationsbranshen. Det är därför jag kritisk granskar alla uttalande som inte är uppbackade av källdata.

Jag hoppas du kan stå ut med det. ;o)

>
>Oj, då... Jag som tog det så basic så att jag var rädd att du skulle bli förnärmad för det...
>Vad är det du menar är svårt att förstå?
>

Låter som sakrkasm för mig. Detta gör mig, i så fall, mycket förnärmad.
Det jag menade med ditt exempel vara att jag inte förstod nyttan av det.
Vilket kan jämföras med att jag inte förstår varför USA torterar fångar i Irak.
Detta beror inte på att jag saknar intiligens eller grundläggande information.
Utan att du inte tydliggjort nyttan i ditt exempel.

JAg hoppas du har överinseende med det.

>> Oj, då... Jag som tog det så basic så att jag var rädd att du skulle bli förnärmad för det...
>> Vad är det du menar är svårt att förstå?
>>
>
> Låter som sakrkasm för mig. Detta gör mig, i så fall, mycket förnärmad.
> Det jag menade med ditt exempel vara att jag inte förstod nyttan av det.
> Vilket kan jämföras med att jag inte förstår varför USA torterar fångar i Irak.
> Detta beror inte på att jag saknar intiligens eller grundläggande information.
> Utan att du inte tydliggjort nyttan i ditt exempel.

Jo, lite sarkasm måste jag erkänna att det slank med, men frågan är uppriktig.

Mitt exempel ÄR verkligen basic, det beskriver vad som händer när man joinar ihop två tabeller, och varför databasen måste använda alla värdena från bägge tabellerna. Det här är grundkursen om hur en relationsdatabas fungerar, ifall vi inte ens är överens om det, så talar vi ju om helt olika saker...

>Jo, lite sarkasm måste jag erkänna att det slank med, men frågan är uppriktig.
>
>Mitt exempel ÄR verkligen basic, det beskriver vad som händer när man joinar ihop två tabeller och
>varför databasen måste använda alla värdena från bägge tabellerna.
>

Håller jag med om. Ett mycket bra exempel där du förklarar tydligt.

Men min uppfattning om att man "måste" jämföra alla poster känns fel för mig. Måste man verkligen det? Om en constraint är baserat på en clustrat index. Borde man kunna använda detta index för att slippa alla poster.

Exempel dax:

Types
+--------+------------+
| TypeId | TypeName |
+--------+------------+
| 0 | Amatör |
| 1 | Användare |
| 2 | Proffs |
| 3 | Guru |
| 4 | Sjöjungfru |
+--------+------------+


Users
+--------+----------+----------+
| UserId | UserType | UserName |
+--------+----------+----------+
| 1 | 3 | Andreas |
| 2 | 1 | Bengt |
| 3 | 2 | Carl |
| 4 | 1 | David |
| 5 | 2 | Erik |
+--------+----------+----------+


Index för constraint mellan Types.TypeId och Users.UserType
+--------+----------+
| UserId | UserType |
+--------+----------+
| 1 | 3 |
| 2 | 1 |
| 3 | 2 |
| 4 | 1 |
| 5 | 2 |
+--------+----------+


Clustrat index för constraint mellan Users.UserType och Types.TypeId
+----------+--------+
| UserType | UserId |
+----------+--------+
| 1 | |
| | 2 |
| | 4 |
| 2 | |
| | 3 |
| | 5 |
| 3 | |
| | 1 |
+----------+--------+

Om man ställer en fråga. T.Ex. :

SELECT Users.*, Types.TypeName AS UserTypeName
FROM Users INNER JOIN Types ON Users.UserType = Types.TypeId

Eftersom inte alla poster från Types används.
Borde man knuna använda index'et för att lista ut vilka de är.

För att slippa göra en table scan i Types tabellen för varje post Users tabellen.
Borde det vara effektivare att slå upp posten från indexet för primärnyckeln i Types, TypeId.

Jag vill bara slippa onödiga poster och operationer. Vill ha effektiva fråger.

<Om en constraint är baserat på en clustrat index. Borde man kunna använda detta index för att slippa <alla poster.

Ett clustrat index ÄR tabellen.

<För att slippa göra en table scan i Types tabellen för varje post Users tabellen.
<Borde det vara effektivare att slå upp posten från indexet för primärnyckeln i Types, TypeId.

Det är effektivare, MEN det clustrade indexet är tabellen. Eftersom du gör en left join, så får du med alla rader från ena tabellen. Då blir det en indexscan= tablescan

Från innan:

Ja det är Northwind mina exempel var baserade på.

Nej Northwind är inte optimal, men "mina" frågor fungerar fortfarande bättre än "dina" även om man optimerar databasen.

/m

Får väl nöja mig med det då. :oP