Faglig nivå på INF3100/INF4100 ved UiO

[roac]

Først: Innlegget hadde sikkert også passet under utdanning, men jeg anser det som mer sannsynlig at noen vilkunne svare meg her (Databaser).

 

Som en del av en Bachelor i Informatikk har jeg planer om å ta INF3100/INF4100 (Databasesystemer) ved UiO, og jeg lurer i den sammenheng om noen her har tatt dette og kan komme med kommetarer om nivået på kurset. Jeg har mer eller mindre sammenhengende jobbet med databasesystemer i nærmere 10 år nå, mend et er selvsagt mye rart man kan ha unngått å komme borti i vesentlig grad, som f eks relasjonsalgebra.

[thomma]

Jeg tok INF3100 i fjor, og er meget fornøyd meg kurset. Det faglige nivået på kurset er relativt høyt. Kurset omhandler mange forskjellige sider av databasen. Du nevnte relasjonsalgebra. I tillegg kommer litt transaksjonshåndtering, hardware, mye SQL!, query optimalisering, objekt /objekt-relasjon databaser osv. Du kan jo laste ned powerpointene fra tidligere år, og se hva som gjennomgås.

 

Kurset krever en del jobb. siden du har jobbet en del med databaser fra før, vil nok noen deler av kurset gå greit, men det kommer nok også en del du ikke har vært borti før.

 

De to obligatoriske oppgavene i kurset er greie nok. Bare sett av nok tid...

[roac]

Høres lovende ut. Takk

[blackbrrd]

Når det er nevnt, hva er relatsjonsalgebra og kunne du linke til ppt slidene?

 

Har jobbet i 5 år med postgresql/java etter 3 år på ingeniørhøgskole, så lurer på om det er noe jeg har gått glipp av

Endret 11. august 2007 av blackbrrd

[roac]

Når det er nevnt, hva er relatsjonsalgebra og kunne du linke til ppt slidene?

 

Har jobbet i 5 år med postgresql/java etter 3 år på ingeniørhøgskole, så lurer på om det er noe jeg har gått glipp av

9259113[/snapback]

http://www.google.no/search?hl=no&q=inf3100

 

Relasjonsalgebra er en matematisk fremstilling av spørringer, som databaseservere benytter for å bestemme hvordan de skal gå frem for å hente dataene. Med relasjonsalgebra kan man (lik annen algebra) da stokke om på formlene, slik at man får forskjellige formler som gir samme resultat, men med forskjellig vanskelighetsgrad av å løse dem. Query Optimizer i en databaseserver har til oppgave å finne den mest effektive metoden, og så benytte denne.

 

Så, når du kan relasjonsalgebra, er du også i stand til å skjønne hvordan databaseservere fungerer ("tenker"), og derved forstå hva som er "galt" når enkelte spørringer plutselig tar veldig lang tid.

 

Sånn kort fortalt.

 

Edit: slides.

Endret 11. august 2007 av roac

[Manfred]

Ikke dumt, så ved å kunne relasjonsalgebra kan man "enkelt" effektivisere store, tunge spørringer? Interessant

 

Litt lesestoff for ferien hehe.

[blackbrrd]

Hmm...

 

Hvordan er det med praktisk anvendelse av kunskaper man har fra relasjonsalgebra? Min erfaring er at alle databaser har quirks i større eller mindre grad. F.eks taklet ikke postgres før versjon X IN spørringer.

 

Det er også ofte at optmizeren bytter om på hvordan den skal kjøre spørringer utfra hvor mye data du har i databasen. F.eks hvis du har LIMIT på en spørring så kan den finne på å kjøre sequential scan hvis den forventer at du skal ha mer enn x% treff, mens du i virkligheten vil ha index scan i alle tilfeller...

 

Det er et par elementære ting man må kunne... f.eks skal du aldri putte LEFT JOIN før INNER JOIN i en spørring i postgres. Da kan optimizeren ved gitte datamengder plutselig slutte å reordre left joinet for deg og så går alt som sirrup. Veldig interessant når databasen tar et sequential scan på en tabell med over 5 millioner rader istedetfor et index scan på 100 rader... Det samme gjelder egentlig alle spørringer - begynn med den tabellen hvor du kan begrense dataene mest.

 

Har også kommet fram til at hvis du må joine to tabeller x og y og det er først kombinasjonen av de to som sier at du skal ha 100 rader, ikke 1 million rader, men du må gjennom 10 tabeller i mellom og både x og y er store tabeller så kommer det til å gå som sirrup...

 

Mao.. det er av og til nødvendig å endre på datastrukturen i databasen for å oppnå akseptabel ytelse. Ett typisk tilfelle er ett lager hvor du skal kunne si hvor mange du har av vare X på lager. Dette er noe du vil holde oppdatert med en trigger, ikke noe du vil fikse med group by og aggregate funksjoner som SUM eller COUNT:

[roac]

Bare for å oppklare. Relasjonsalgebra har intet med SQL å gjøre, men hvordan databaseserven jobber for å hente ut dataene, og derved hva den gjør feil. Hvis det er noe man skal bruke relasjonsalgebra til, så er det å se på execution plan, men jeg har ikke gravd meg langt nok ned i dette til å komme med noe detaljert. (Det er enda et år til jeg jeg skal ta faget)

[blackbrrd]

Hvordan du skriver SQL-en har veldig mye med hvordan databaseserveren jobber for å hente dataene. Mao har relasjonsalgebra veldig mye å gjøre med sql.

 

Det blir vel noe slikt som dette:

SQL -> relasjonsalgebra for å execution plan -> execute plan -> deliver data

[Ueland]

Det har vel da strengt tatt alt med SQL-oppbygning å gjøre?

 

Det finnes ørten måter å hente ut samme datasett på fra SQL, men rekkefølgen på kriteriene kan bestemme om serveren kneler eller ikke ved stor trafikkmengde...

[roac]

Det har vel da strengt tatt alt med SQL-oppbygning å gjøre?

 

Det finnes ørten måter å hente ut samme datasett på fra SQL, men rekkefølgen på kriteriene kan bestemme om serveren kneler eller ikke ved stor trafikkmengde...

9261157[/snapback]

Hvis du har en råtten databasemotor som ikke klarer å gjøre noe optimalisering selv, så henger relasjonsalgebraen tettere opp mot SQL enn ellers. Men det er verdt å merke seg at databaser ikke er synonymt med SQL, det er også flere databaser som benytter seg av andre språk for spørringer, og relasjonsalgebra gjelder for disse også. Men som du er inne på, du kan bruke relasjonalgebraen til å tweake på rekkefølgen i uttrykkene dine, og håpe at query optimizer ikke optimaliserer spørringen likt som forrige gang.

 

Et eksempel på en databasemotor med god query optimizer er SQL Server 2005, og ved en anledning skrev jeg 5-6 forskjellige spørringer for å få ut det samme resultatsettet for å PRØVE å få den til å klikke på en av dem, uten å lykkes. Uansett hvordan jeg skrev spørringen fant SQL Server 2005 den samme, og beste, execution plan.

 

Men, nå skal ikke jeg prøve å grave meg enda lenger ned i dette, for da tror jeg at jeg må opp med læreboka å lese litt først

[blackbrrd]

Hvor kompleks var spørringen du skrev? Hvor store datamengder var det snakk om? Det er jo to ting som er verdt å tenke på.

 

Spørringene jeg har hatt problemer med har involvert relativt store datamengder (millioner av rader pr tabell) i en spørring på 10-15 joins. Det står også eksplisitt at rekkefølgen på joinene blir brukt som "hint" av query optmizeren i postgres.

 

Har ikke brukt SQL server på over fem år nå og jeg har definitivt mer erfaring nå enn jeg hadde da, så det kan jo godt hende at optimizeren dens er bedre enn postgres sin? Når vi portet en applikasjon fra SQL server til Postgres for 5 år siden så var det ingen merkbar forskjell i ytelse...

 

Hmm.. sjekket akkurat changeloggen til postgres 8.2 (nyeste versjon) og ett av punktene var:

Many query optimization improvements, including support for reordering outer joins

 

Mao så gikk det an i tidligere versjoner av postgres å skrive spørringer som var langt fra optimale ved å legge inn left joins før inner joins. Utfra hva du sier roac, så høres det ut som mssqlserver har hatt den muligheten (lenge?)?

Endret 12. august 2007 av blackbrrd

[roac]

Mao så gikk det an i tidligere versjoner av postgres å skrive spørringer som var langt fra optimale ved å legge inn left joins før inner joins. Utfra hva du sier roac, så høres det ut som mssqlserver har hatt den muligheten (lenge?)?

9262539[/snapback]

Reorganisering av joins har i hvert fall vært med siden SQL Server 2000, mao nå i sju år. Akkurat når det kom i SQL Server og andre databasemotorer skal jeg ikke si for sikkert, men dette er en viktig i enterprise-level databaser. Databaseserverene bruker da statistikk fra de enkelte tabellene i kombinasjon med relasjonsalgebra til å vurdere størrelsen av blant annet midlertidige resultatsett, slik at de kan utføre spørringene så effektivt som mulig.

[blackbrrd]

Postgres har reorderet inner joins hele tida, bare outer joins som ikke ble reorderet... 99% av tida skal man putte left joins til slutt så det er stort sett ikke så farlig...