SQL gammel syntax, kompleksitet

[hightow]

Hvor kompleks kan en slik query bli?

Jeg vil f.eks joine samme tabellen flere ganger i queryen, men det går jo ikke.

 

ANSI-standard:

Select a.name, b.name

From maintable main

join table1 a on a.ref_main = main.ref

join table1 b on b.ref_main = main.ref

Where (a.type = 1)

and (a.type = 2)

 

Hvordan blir denne Sql'en seende ut med gammel syntaks?

[blackbrrd]

Du kan joine inn samme tabell flere ganger. Du kan bruke UNION og indre spørringer, du kan joine sammen flere spørringer, etc, etc.

 

Mao, sql setninger kan bli VELDIG komplekse, men da kan også ytelsen gå til helvete, så du ender opp med å måtte skrive 3-4 spørringer og merge dem i kode.

[hightow]

Den OLE-DB-provideren jeg bruker, støttes bare gammel SQL-syntaks. Dvs jeg kan ikke brukes JOINs, subselects, etc.

 

F.eks denne queryen i ANSI(92?)-standard

Select a.field1, b.field2

From tableA a

join tableB b on b.ref_a = a.ref

 

.. må jeg skrive slik:

Select tableA.field1, tableB.field2

From tableA, tableB

Where tableA.ref = tableB.ref_a

[roac]

hightow mener vel noe i retning av:

 

Select a.name, b.name

From maintable main,

table1 a,

table1 b

Where

(a.ref_main = main.ref) and

(b.ref_main = main.ref) and

(a.type = 1) and (b.type = 2)

 

SQL Spørringer kan bli svært komplekse, og med fornuftig indeksering ofte uten at det går vesentlig på bekostning av ytelsen. Seriøse databasemotorer har en svært god Query Optimizer som i de aller fleste tilfellene klarer å justere execution plan slik at den blir så effektiv som mulig. Personlig har jeg i SQL Server 2005 hatt en relativt komplesks spørring som jeg har PRØVD å få forskjellig execution plan på ved å skrive spørringen på ymse måter, uten å lykkes.

 

Men, la meg for ordens skyld påpeke at blackbrrd har et poeng. Hvis spørringer blir for komplekse kan det lønne seg å skrive om spørringen. Et eksemel kan være en subquery i en where clause. Denne kan ved store mengder data med fordel byttes ut med en midleritidig tabell, som man i steden bruker et join mot.

[hightow]

Jeg vet ikke om dere helt har forstått syntaksen...

Hverken bruk av aliaser eller subquery eller joins støttes.

Uansett problemet er forsåvidt løst ved at jeg bruker en annen oledb-provider ...

Takk for innsatsen

[blackbrrd]

Optimizeren klarer 99% av gangene å optimalisere en spørring, f.eks spiller det sjeldent noen rolle hvor mange joins du har etc, etc... Problemet kommer oftest hvis man skal joine inn en spørring så man får flere kolonner, hvis man har en indre spørring i select clausen, eller tilsvarende. Hvis man har en indre spørring i where clausen så er det sjeldent noe problem HVIS den egentlig kunne ha blitt løst som en join, men det bare hadde gjort det vanskeligere å lese spørringen.

 

Det kommer også litt an på datamengden det er snakk om... Har vært borti å skulle joine sammen fem tabeller (veldig store, 1mill+ rader) og begrensningen har vært i tabell 1 og tabell 5. Mao at med bare begrensningen i tabell 1 får man en million treff, og med bare begrensning i tabell 5 så får man en million treff. Resultatet var at optimizeren måtte joine inn så å si alt av rader i tabell 1-4 før den fikk begrenset det i tabell 5. Det går bare tregt

 

(når jeg sier tabell 1 og 5, så mener jeg at for å få joinet inn tabell 5 så må du joine tabell 1 på 2, 2 på 3, 3 på 4 og 4 på 5)

Endret 2. juni 2007 av blackbrrd