Hej!

Det känns som att jag är riktigt korkad nu, kan kanske bero på den utmärkta Oktoberfest-ölen jag drack igår?
;-)

Jag joinar ett antal tabeller och vill till resultatet addera en kolumn som anger huruvida ett värde i en kolumn finns i en annan (kopplings)tabell. Om vi inte låtsas om joinarna kan vi säga att det ser ut såhär:

Ordrar
---------------
OrderID (PK)
ArtikelID (FK)
OrderInfo


RestadeArtiklar
-----------------
OrderID (FK)
ArtikelID (FK)

Nu skulle jag vilja få ut ett resultat som ser ut typ såhär:

OrderID|OrderInfo|ArtikelID|Restnoterad
-------------------------------------------
1223 |Qwertyuioi|3223 | True
1223 |Asdfghjklö|3224 | False
1224 |Zxcvbnm,.|3223 | False
1224 |Åpoiuytrew|3224 | False

OrderID, OrderInfo och ArtikelID skulle alltså komma ut från tabellen Ordrar (som i själva verket är resultatet från en jon med diverse tabeller jag inte listat). Kolumnen Restnoterad skulle ange huruvida respektive posts ArtikelID från den tabellen (joinen) finns med i tabellen RestadeArtiklar.

Några tips på hur jag skulle kunna skapa/addera kolumnen Restnoterad?
Jag använder MS SQL Server 7.

mvh
/Jonas

Så här kanske?
<code>
SELECT OrderID, ArtikelID, OrderInfo,
(OrderID IN (SELECT OrderID FROM RestadeArtiklar WHERE RestadeArtiklar.ArtikelID =
Ordrar.ArtikelID)) AS Restnoterad
FROM Ordrar
</code>

Hej Per!

Jag får tyvärr inte SQL Server 7 att acceptera syntaxen. Den gillar inte konstruktionen med "ORDERID IN".

Nu har jag i o f s löst problemet, genom att köra två queries, loopa igenom resultatet och addera kolumnen i min C#-kod istället. Men jag har ändå en gnagande känsla av att jag gjort ungefär det här med SQL förr, så jag tar gärna emot fler tips!

mvh
/Jonas

Order är ett reserverat ord i SQL. Döp om det eller använd ""

Hej Gert!
Det är tyvärr inte problemet. (Ordet order används f.ö. ingenstans i queryn... :-)
mvh

/Jonas

Det "rätta" sättet att åstadkomma detta sql-mässigt borde vara med en left join:
<CODE>
SELECT O.OrderID, O.OrderInfo, O.ArtikelID,
CASE WHEN R.ArtikelID IS NULL THEN 0 ELSE 1 END RestNoterad
FROM Ordrar O LEFT JOIN RestadeArtiklar R ON R.ArtikelID = O.ArtikelId AND R.OrderID = O.OrderID
ORDER BY OrderID, ArtikelID
</CODE>

Denna sql-sats returnerar 1 eller 0 i kolumnen restnoterad, vilket är att rekommendera om man använder boolska värden i sql.

/Pelle

Borde inte <b>CASE WHEN R.ArtikelID IS NULL THEN 0 ELSE 1 END</b> lika gärna kort och gott kunna skrivas <b>R.ArtikelID IS NOT NULL</b>?

Förvisso, om SQL server hade haft stöd för datatypen boolean.

Så det fungerar inte som i MySQL? Där representeras booleska värden av talen 0 och 1, så att skriva t.ex. <b>SELECT 5 > 3;</b> ger talet 1 som resultat och <b>R.ArtikelID IS NOT NULL</b> skulle ge talet 1 om R.ArtikelID inte är null och talet 0 om R.ArtikelID är null.

Nej, det fungerar inte som i Mysql och tur är väl det. Den bristfälliga typhanteringen i Mysql ger upphov till en hel del fel.

Men även möjligheter... Kan du ge exempel på när det ger upphov till fel?

Om man som jag är van vid C, borde man inte ha några problem med MySQLs typhantering.

Jag tycker att det är litet sjukt om MSSQL stödjer booleska uttryck (t.ex. i WHERE-delar) men inte kan exportera booleska värden.

När man lagrar boolska värden i MSSQL kan man använda datatypen BIT. Denna har värdena 1 respektive 0. Däremot är detta inte samma sak som true och false i uttryck i sql-satsen.

Kan du ge något exempel på när det blir fel med MySQLs "bristfälliga" typhantering?

Mysql tycker att den 30:e februari är ett giltigt datum.
Om man försöker stoppa in en sträng i en numerisk kolumn så lagras värdet 0 istället för att ge fel.
Aritmetik för typen decimal ger avrundningsfel eftersom alla beräkningar görs med float.
Man får felaktigt resultat vid heltalsdivison.
Man kan jämföra kolumner som det inte är relevant att jämföra vilket kan ge oväntade resultat.
Generellt så går det att skriva SQL-satser som är nonsens ur en semantisk aspekt.

<b>Mysql tycker att den 30:e februari är ett giltigt datum.</b>

Oj, det gillade jag inte.



<b>Om man försöker stoppa in en sträng i en numerisk kolumn så lagras värdet 0 istället för att ge fel.</b>

Inte nödvändigtvis talet 0. Stoppar man in '123abc' lagras talet 123. Detta kan vara användbart, även om man kanske hellre markerar konverteringen genom en konverteringsoperator.



<b>Aritmetik för typen decimal ger avrundningsfel eftersom alla beräkningar görs med float.</b>
<b>Man får felaktigt resultat vid heltalsdivison.</b>

Det låter inte bra. Kan du ge exempel?



<b>Man kan jämföra kolumner som det inte är relevant att jämföra vilket kan ge oväntade resultat.</b>

Och varför skulle man göra detta?



<b>Generellt så går det att skriva SQL-satser som är nonsens ur en semantisk aspekt.</b>

Nonsens eller icke-nonsens om man accepterar automatiska typkonverteringar? (Precis som i PHP)

4/5 skall ge 0 ger 0.8 i Mysql.

Att man kan få avrundningsfel när man summerar float-värden är inget konstigt.

<citat>
Och varför skulle man göra detta?
</citat>

T.ex. om du skriver fel kolumnnamn, dvs gör ett misstag.

<citat>
Nonsens eller icke-nonsens om man accepterar automatiska typkonverteringar?
</citat>

Det är strikt definierat i SQL-standarden när man måste använda explicit typkonvertering och dessa regler följs inte av Mysql.

<b>4/5 skall ge 0 ger 0.8 i Mysql.</b>

Det finns en operator DIV som man kan använda.


Har du någon länk till SQL-standarden?

Länk till ANSI SQL-92 standard:

http://www.contrib.andrew.cmu.edu/~shadow/sql/sql1992.txt

Tack, men jag hittar inget där om att division av heltal skall ge ett heltal...

Det där dokumentet är inaktuellt sedan länge. Det senaste standarden heter SQL 2003 och den gäller sen i mars i år.

Det som står i standarden angående division är att resultatypen är implementation-defined (vilket i sig är olyckligt). Programmeringsmässigt så brukar heltalsdivision ge ett heltal som resultat och så fungerar de flesta andra SQL-implementationer. Just detta att Mysql avviker från standard (t.ex hur || tolkas) gör det svårt för dem som vill skriva portabel SQL.

<b>Programmeringsmässigt så brukar heltalsdivision ge ett heltal som resultat</b>

Så vanligt tror jag inte att det är om man ser till antalet språk. De flesta i C-familjen gör det, men utanför C-familjen är det väl inte så vanligt?

Jo. Men nästan ingen stöder väl den än i någon implementation? SQL Server 2000 är entry level ANSI SQL-92 compliant vad jag kan minnas.

Är java i C-familjen? :)

Jo, Java tillhör det jag kallar C-familjen. Språken där har i grunden samma syntax: man använder { och } för satsblock, tilldelning (=) är en operator med ett värde, likhetsoperatorn har dubbla likhetstecken (==), if-satsen saknar ordet 'then', ...