---

Hej.

Jeg har nu gennemgået noget læsestof, men er i vildrede over nogle begreber,
som jeg ikke kan hitte rundt i på nuværende tidspunkt.

Kan i hjælpe med at få definitionerne sat på plads for følgende begreber:

Stored procedure
Views
Transaction
Information Schema
Triggers

---

Frederiksen skrev:

> Kan i hjælpe med at få definitionerne sat på plads for
> følgende begreber:

Er det generel databaseteori eller i forhold til et bestemt
databaseprogram?

Nå - til sagen.

> Stored procedure

En procedure består af en række sql-sætninger der er gemt direkte i
databasen. Proceduren kan tage en eller flere parametre og evt.
returnere en værdi eller et postsæt.

> Views

Et view (visning) er næsten hvad ordet lægger op til - et udvalgt
kig på nogle data. Det er grundlæggende en SELECT-forespørgsel hvor
man kan udvælge bestemte felter (kolonner) og/eller poster
(rækker). Visninger kan anvendes som tabeller i mange sammenhænge -
således at man kan lave select på en visning, oprette en ny visning
fra en eksisterende visning etc.

Visningen kan dog ikke indeholde sortering.

> Transaction

En transaktion er en gruppe sammenhørende sql-kommandoer. Det er
databasens ansvar at sikre at en transaktion enten fuldføres
(committes) eller slet ikke udføres (abort/rollback). Det må ikke
være muligt at dele af en transaktion udføres mens andre dele af
den ikke udføres.
Et klassisk eksempel er de handlinger der skal udføres når man
hæver penge i en bank. Enten skal bankkontoen opdateres og kunden
have penge i hånden, eller også skal bankkontoen ikke opdateres og
kunden ikke få nogen penge.

> Information Schema

- er nogle standardiserede visninger af systemoplysninger for en
database. Oplysninger om tabeller, felter, constraints og meget
andet er typisk gemt i systemtabeller i databasen. Navngivningen på
disse tabeller kan vist nok variere en del alt efter
databaseprogrammet, men hvis databasen har implementeret
information schema views, kan man bruge samme metode til at få
oplysninger om databasens metadata.

> Triggers

En trigger er en stump sql-kode man knytter til en bestemt handling
på et bestemt objekt. Det kan fx være noget kode der skal køres
hver gang kundetabellen opdateres. Databasen holder styr på at
kalde triggeren når den bestemte objekt/hændelses-kombination
forekommer. Ofte giver databasen triggeren mulighed for både at
"se" data før og efter en ændring (så man fx kan sammenligne et
felt før og efter det bliver opdateret).
--
Jens Gyldenkærne Clausen
Svar venligst under det du citerer, og citer kun det der er
nødvendigt for at forstå dit svar i sammenhængen. Se hvorfor og
hvordan på http://usenet.dk/netikette/citatteknik.html

---

Jens Gyldenkærne Clausen, <jens@gyros.invalid>
in Xns97CF42782830jcdmfdk@gyrosmod.cybercity.dk
among other things wrote:

<en rigtig god forklaring>

men

> Visningen kan dog ikke indeholde sortering.

Passer vist ikke helt. Har lige tjekket et par views
(Oracle) som fint sorterer med ORDER BY <column>

--
Go on punk - make my day!
Neil Southwood

---

Neil Southwood skrev:

>> Visningen kan dog ikke indeholde sortering.
>
> Passer vist ikke helt. Har lige tjekket et par views
> (Oracle) som fint sorterer med ORDER BY <column>

O.k. - jeg kender primært visninger fra MSSQL. Jeg kan se at også
MySQL tillader ORDER BY i et view - med den note at sorteringen
bliver ignoreret hvis der sorteres i den select-sætning der henter
fra visningen.
--
Jens Gyldenkærne Clausen
Svar venligst under det du citerer, og citer kun det der er
nødvendigt for at forstå dit svar i sammenhængen. Se hvorfor og
hvordan på http://usenet.dk/netikette/citatteknik.html

---

"Jens Gyldenkærne Clausen" <jens@gyros.invalid> skrev i en meddelelse
news:Xns97CF42782830jcdmfdk@gyrosmod.cybercity.dk...


Hej Jens.

Tak for mgode svar.

>
>> Kan i hjælpe med at få definitionerne sat på plads for
>> følgende begreber:
>
> Er det generel databaseteori eller i forhold til et bestemt
> databaseprogram?
>
> Nå - til sagen.
>
>> Stored procedure
>
> En procedure består af en række sql-sætninger der er gemt direkte i
> databasen. Proceduren kan tage en eller flere parametre og evt.
> returnere en værdi eller et postsæt.
>
>> Views
>
> Et view (visning) er næsten hvad ordet lægger op til - et udvalgt
> kig på nogle data. Det er grundlæggende en SELECT-forespørgsel hvor
> man kan udvælge bestemte felter (kolonner) og/eller poster
> (rækker). Visninger kan anvendes som tabeller i mange sammenhænge -
> således at man kan lave select på en visning, oprette en ny visning
> fra en eksisterende visning etc.
>
> Visningen kan dog ikke indeholde sortering.
>
>> Transaction
>
> En transaktion er en gruppe sammenhørende sql-kommandoer. Det er
> databasens ansvar at sikre at en transaktion enten fuldføres
> (committes) eller slet ikke udføres (abort/rollback). Det må ikke
> være muligt at dele af en transaktion udføres mens andre dele af
> den ikke udføres.
> Et klassisk eksempel er de handlinger der skal udføres når man
> hæver penge i en bank. Enten skal bankkontoen opdateres og kunden
> have penge i hånden, eller også skal bankkontoen ikke opdateres og
> kunden ikke få nogen penge.
>
>> Information Schema
>
> - er nogle standardiserede visninger af systemoplysninger for en
> database. Oplysninger om tabeller, felter, constraints og meget
> andet er typisk gemt i systemtabeller i databasen. Navngivningen på
> disse tabeller kan vist nok variere en del alt efter
> databaseprogrammet, men hvis databasen har implementeret
> information schema views, kan man bruge samme metode til at få
> oplysninger om databasens metadata.
>
>> Triggers
>
> En trigger er en stump sql-kode man knytter til en bestemt handling
> på et bestemt objekt. Det kan fx være noget kode der skal køres
> hver gang kundetabellen opdateres. Databasen holder styr på at
> kalde triggeren når den bestemte objekt/hændelses-kombination
> forekommer. Ofte giver databasen triggeren mulighed for både at
> "se" data før og efter en ændring (så man fx kan sammenligne et
> felt før og efter det bliver opdateret).
> --
> Jens Gyldenkærne Clausen
> Svar venligst under det du citerer, og citer kun det der er
> nødvendigt for at forstå dit svar i sammenhængen. Se hvorfor og
> hvordan på http://usenet.dk/netikette/citatteknik.html

---

Martin Christensen skrev:

> En stored procedure er meget mere end SQL, hvilket jeg er
> sikker på, du udmærket ved, men måske ikke lige overvejede
> fordi Transact-SQL - ligesom PL/SQL o.l. - ligner og
> integrerer ren SQL.

Du har helt ret. Når jeg ikke fik nævnt andet end sql-muligheden,
er det nok i første omgang fordi 95 % af min praktiske
databaseerfaring stamme fra MSSQL 2000 - hvor sp'er kun kan skrives
i (T-)SQL.

I MSSQL 2005 kan man også lave sp'er i et .NET-sprog (c#, vb.net
o.l.), men det er ikke noget jeg har erfaring med. Og mulighederne
i andre databasesystemer ved jeg kun ganske lidt om.
--
Jens Gyldenkærne Clausen
Svar venligst under det du citerer, og citer kun det der er
nødvendigt for at forstå dit svar i sammenhængen. Se hvorfor og
hvordan på http://usenet.dk/netikette/citatteknik.html

---

Frederiksen skrev:

> Tak for mgode svar.

Velbekomme. Hvis du vil gøre lidt til gengæld, må du gerne læse min
signatur.
--
Jens Gyldenkærne Clausen
Svar venligst under det du citerer, og citer kun det der er
nødvendigt for at forstå dit svar i sammenhængen. Se hvorfor og
hvordan på http://usenet.dk/netikette/citatteknik.html

---

Jens Gyldenkærne Clausen <jens@gyros.invalid> writes:

>> Stored procedure
>
> En procedure består af en række sql-sætninger der er gemt direkte i
> databasen. Proceduren kan tage en eller flere parametre og evt.
> returnere en værdi eller et postsæt.

En stored procedure er meget mere end SQL, hvilket jeg er sikker på,
du udmærket ved, men måske ikke lige overvejede fordi Transact-SQL -
ligesom PL/SQL o.l. - ligner og integrerer ren SQL.

En stored procedure _kan_ muligvis være ren SQL, men skrives oftere i
et procedurisk sprog. SQL i sig selv indeholder ingen muligheder for
at bruge variable, løkker og så meget andet, vi kender fra normal
programmering, så derfor har de fleste DMBS'er et indbygget
programmeringssprog, som man kan skrive stored procedures i. Hvorfor
ikke bare have koden et andet sted end i databasen? Tjo, oftest af
hensyn til performance og sikkerhed: når man lægger funktionaliteten i
DB'en, bliver man fri for at sende en masse data unødigt frem og
tilbage over netværket; og hvad sikkerhed angår, man man gemme en
masse ting bag stored procedures (fx: denne bruger må ikke direkte
tilgå tabellen med passwords, men han må godt bruge en stored
procedure, der kan bekræfte, at et password er korrekt eller ej).

Martin

---

Jens Gyldenkærne Clausen <jens@gyros.invalid> writes:

> Du har helt ret. Når jeg ikke fik nævnt andet end sql-muligheden, er
> det nok i første omgang fordi 95 % af min praktiske databaseerfaring
> stamme fra MSSQL 2000 - hvor sp'er kun kan skrives i (T-)SQL.

Min erfaring (primært med PL/SQL) er også, at langt størstedelen af de
funktioner, jeg har lavet, kun lige har behov for 'SQL+epsilon'. De
funktioner (uden for det ERP-system, jeg har arbejdet med), hvor jeg
virkeligt har haft behov for alle et procedurisk sprogs muligheder, er
forholdsvist sjældne, men ikke dermed mindre væsentlige.

> I MSSQL 2005 kan man også lave sp'er i et .NET-sprog (c#, vb.net
> o.l.), men det er ikke noget jeg har erfaring med. Og mulighederne
> i andre databasesystemer ved jeg kun ganske lidt om.

Jeg har primært arbejdet med PostgreSQL, som har sin egen
PL/SQL-pendent (PL/pgSQL) samt har mulighed for at benytte Perl,
Python og vist nok også TCL; og Oracle, som har PL/SQL og Java. Til de
fleste ting ville jeg dog foretrække DB'ens eget sprog (T-SQL, PL/SQL,
PL/pgSQL), da de gør databasenært arbejde meget enkelt, i og med de
inkorporerer SQL på det mest grundlæggende plan. Jeg ville kun vælge
andre sprog, hvis jeg havde at gøre med krævende forretningslogik,
hvor der blev stillet væsentligt større krav til fx strengoperationer,
specifik talknuseri e.l. end et nært tilhørsforhold til databasen. I
de tilfælde ville jeg dog også være taknemmelig for de andre sprog:
jeg har før skrevet små Python-programmer til at generere PL/SQL-kode
for mig, når sidstnævnte blev alt for trægt at arbejde med. Det er i
det hele taget meget sigende, at man med fx PL/SQL ikke altid kan
skrive sine stored procedures så pænt, at man kan undgå, at genereret
kode kan betale sig.

Martin