sql fråga.

Hejsan!

Jag håller på ett program som ska söka efter ändringar i en Oracle DB.
Jag har två tabeller, en för status och en för datat (CLOB).
Har delat på dom för att datat kan vara väldigt stora filer och då vill jag undvika att behöva söka i den tabellen hela tiden.

Så här ser tebellerna ut.

Tabell 1, job:
job_id job_status
-------------

tabell 2, job_data:
id job_id job_data

Frågan är:
För att få bra prestanda, hur ska jag skriva sql-frågan bäst?

Jag har funderat på nån av dessa tre:
1)

SELECT job_data.job_data
FROM job_data
WHERE job_data.job_id IN (SELECT job.job_id FROM job WHERE job.job_status = "READY")

SELECT job_data.job_data
FROM (SELECT job_id FROM job WHERE job.job_status = "READY"), job_data
WHERE job.job_id = job_data.job_id

SELECT job_data.job_data
FROM job_data
WHERE (job.job_id = job_data.job_id) AND (job.job_status = "READY")

Du kan ju testa köra frågorna och jämföra tider. Nu är jag inte så insatt i prestanda, men jag antar att det borde gå snabbare om du talar om för sql-servern vilken typ av join du vill använda, typ:

SELECT job_data.job_data
FROM job_data
INNER JOIN job ON job.job_id = job_data.job_id
WHERE job.job_status = 'READY'

Jag har faktiskt inte något större begrepp om hur det lönar sig, men läs lite mer om optimering i oracle, Understanding Joins.

Hej Engine^.

Jag tror inte det blir nån prestandaökning om man använder join. :(

Helst vill jag ha en fråga som är "två-delad". Den ska söka i job-tabellen efter ändringar i status, och bara om den får några träffar där ska den hämta job_datat med samma job_id.

Dina exempel två och tre är exempel på implicita joins.

Jag skulle nog köra med ditt första exempel, eftersom det ser snabbast ut (när jag tittar på det ;)). Det är vad jag tänker när du skriver "två-delad".

Prestandaökning vid joins var kanske det jag tänkte mest på, utan hur du undviker prestandaförluster vid join. T.ex. så kan det vara en stor fördel att ha indexerade FK. Nu verkar du inte ha någon sådan relation i dina tabeller, men det är en fördel att ha "smart" design på databasen innan man lägger in massa data :)

Det finns ingen anledning att använda två tabeller.

Hej,

Jag har Primary Key mellan job_id.

Kan en View vara ett alternativ?

Jag antar också att det borde vara bättre med en fråga som hämtar allt nytt, än att ha flera frågor som hämtar en i taget.
Job_data tabellen kan vara flera gig stor, där varje job_data fält kan var från några meg till hundratals meg.

Det finns ingen anledning att använda två tabeller.

Anledningen till två tabeller är att flera applikationer kommer att läsa/skriva till job_status tabellen. Tanken var då att man inte ska behöva jobba med en tabell som kan blir flera gig (>100 gig) stor.

Men jag tar gärna imot tips. ;)

Du kanske kan köra ett analysprogram på din databas och se om optimeringen fungerar som den ska. Trial and error brukar hjälpa en på vägen ;)

Testa, testa och testa igen...

Lobdata lagras separat. Det som finns i tabellen är bara en locator. En sökning i eller uppdatering av icke-lob kolumner innebär inte att man läser in hela loben i minnet.

Lobdata lagras separat.

Det har du helt rätt i, hur kan jag ha glömt det...! Tack!
Då finns det inga bra tips som gäller specielt för lob-fält?

Tack för hjälpen!