---

Hej

Er ved at lave et lille website, og kom til at tænke over, hvornår man
burde hardcode sine SQL statements i ASP'en og hvornår man burde
lave dem som stored procedures.

Min fornuft fortæller mig at man altid burde bruge stored procedures,
men ud over at de ligger centralt og dermed er lettere at fejlrette, kan
jeg ikke lige komme på noget....

Er der andre gode/bedre grunde?

--
T

---

> Er ved at lave et lille website, og kom til at tænke over, hvornår man
> burde hardcode sine SQL statements i ASP'en og hvornår man burde
> lave dem som stored procedures.
>
> Min fornuft fortæller mig at man altid burde bruge stored procedures,
> men ud over at de ligger centralt og dermed er lettere at fejlrette, kan
> jeg ikke lige komme på noget....
>
> Er der andre gode/bedre grunde?

Forbedret performance er vel den helt afgørende grund til at bruge stored
procedures, idet databasen optimerer søgningen bedre.

Kim

---

"Hans Nielsen" <hn33211___spam@hotmail.com> wrote in message
news:3d3f8379$0$11802$edfadb0f@dspool01.news.tele.dk...
> Hej
>
> Er ved at lave et lille website, og kom til at tænke over, hvornår man
> burde hardcode sine SQL statements i ASP'en og hvornår man burde
> lave dem som stored procedures.
>
> Min fornuft fortæller mig at man altid burde bruge stored procedures,
> men ud over at de ligger centralt og dermed er lettere at fejlrette, kan
> jeg ikke lige komme på noget....
>
> Er der andre gode/bedre grunde?

-Anvendelse af stored procedures (SP) giver forbedret performance (som Kim
også skriver). Grunden hertil er at der for koden i SP genereres en optimal
execution plan under første kørsel, således efterfølgende kørsler vil være
væsentlig hurtigere. Så afhængigt at kompleksiteten kan du forvente en
makant bedre performance.
-Central beliggenhed, med et godt brugerinterface giver SP også (som du selv
skriver).
-Mere simpel ASP kode, fordi funktionaliteten er gemt væk i SP
-Portabilitet: du kan umiddelbart anvende de samme SP i fx Access eller fx
VB unden at skulle til at klippe-klistre/tilrette.
--
Frederik Jensen, Judex

---

"Hans Nielsen" <hn33211___spam@hotmail.com> wrote:

> Er ved at lave et lille website, og kom til at tænke over, hvornår man
> burde hardcode sine SQL statements i ASP'en og hvornår man burde
> lave dem som stored procedures.
>
> Min fornuft fortæller mig at man altid burde bruge stored procedures,
> men ud over at de ligger centralt og dermed er lettere at fejlrette, kan
> jeg ikke lige komme på noget....
>
> Er der andre gode/bedre grunde?

Du skal IKKE bruge stores procedures hvis:

- Du skal regne urimeligt meget på de data du trækker fra databasen.
- Det er den mindste mulighed for at skulle flytte til en anden database.

Små web sites vokser i enkelte tilfælde til store web sites med mange hits,
det er ikke så svært/dyrt at skalere web servere som det er at skalere
database serveren.

SQL server dyr hvis den skal være stor, derfor kan det være en fordel at
holde døren åben for andre produkter.

Jeg kan se at du har fået mange andre gode grunde til at bruge SP, så nu kan
du sikkert bedre beslutte dig.


--
Med Venlig Hilsen

Ulrik Lunddahl - nospam037@lunddahl.dk
My heroes: Heddy Lamar & George Antheil

---

"Ulrik Lunddahl" <nospam037@lunddahl.dk> wrote in message
news:ahoolp$q7d$1@sunsite.dk...
> "Hans Nielsen" <hn33211___spam@hotmail.com> wrote:
>
> > Min fornuft fortæller mig at man altid burde bruge stored procedures,
> > men ud over at de ligger centralt og dermed er lettere at fejlrette, kan
> > jeg ikke lige komme på noget....
> >
> > Er der andre gode/bedre grunde?
>
> Du skal IKKE bruge stores procedures hvis:
>
> - Det er den mindste mulighed for at skulle flytte til en anden database.
>
Hmm, det ville jo netop være en god grund til at lave SP's
Når man indlejrer T-SQL i sine ASP scripts, så er man jo lidt på herrens
mark, hvis man skal portere koden til et nyt RDBMS, da megen T-SQL ikke er
complaint med fx P-SQL og vice versa

Ved at bruge SP's kan man bibeholde sit præsentationslag as is, og ændre
alle SP's til det ny system

Just my two cents

- Peter Lykkegaard

---

"Peter Lykkegaard" <polonline@hot.mail.com> wrote

> Hmm, det ville jo netop være en god grund til at lave SP's
> Når man indlejrer T-SQL i sine ASP scripts, så er man jo lidt på herrens
> mark, hvis man skal portere koden til et nyt RDBMS, da megen T-SQL ikke er
> complaint med fx P-SQL og vice versa
>
> Ved at bruge SP's kan man bibeholde sit præsentationslag as is, og ændre
> alle SP's til det ny system

Hvis man holder logikken i ASP eller hvilket script sprog man nu benytter og
kun benytter databasen til data, er det ganske trivielt at skifte database,
placerer man logik i databasen bliver det i næsten alle tilfælde sævrt at
konvertere.

Så min pointe var at holde logikken væk fra databasen, ikke om den skulle
placeres i SQL kald til databasen, eller i SP.

--
Med Venlig Hilsen

Ulrik Lunddahl - nospam037@lunddahl.dk
My heroes: Heddy Lamar & George Antheil

---

"Ulrik Lunddahl" <nospam037@lunddahl.dk> wrote in message
[klip]
> Hvis man holder logikken i ASP eller hvilket script sprog man nu benytter
og
> kun benytter databasen til data, er det ganske trivielt at skifte
database,
> placerer man logik i databasen bliver det i næsten alle tilfælde sævrt at
> konvertere.

Måske et spørgsmål om fremsynethed og religion. Jeg foretrækker at lægge så
meget så mulig logik i databasen, således det er nemmere at udskifte
præsentationslaget.

Hvis man anvender SQL Server, synes jeg det vil være ærgeligt hvis man kun
anvender den til datastore. Serveren indeholder mange potente faciliteter,
herunder stored procedures, der kan implementere kompleks logik. Anvendes
serven kun til datastore er det overkill. Her kan Access fx bruges i stedet
(el. andre).

I øvrigt understøtter DB2 også stored procedures, hvilke relativt ubesværet
kan portes fra SQL Serveren.

--
Frederik Jensen, Judex

---

"Frederik Jensen" <fj@judex.dk> wrote:

> Måske et spørgsmål om fremsynethed og religion. Jeg foretrækker at lægge
så
> meget så mulig logik i databasen, således det er nemmere at udskifte
> præsentationslaget.

Det er i høj grad et spørgsmål om fremsynethed, og desværre også religion.

Den optimale løsning må være at putte logikken i et logisk lag, og udnytte
de stærkeste værktøjer til dette.

et kan være en tung process at komme i gang med, så der skal overvejes nøje
før man går i gang, jeg tror de fleste kan skrive med om hvordan en portning
var tungere end forventet, og at et næsten altid er sværere end et kode nyt.

Psykologisk er det ofte også tungere for alle de involverede parter, da
resultatet som oftes ikke kan ses og føles på på samme måde som når der
skabes nyt.

> Hvis man anvender SQL Server, synes jeg det vil være ærgeligt hvis man kun
> anvender den til datastore. Serveren indeholder mange potente faciliteter,
> herunder stored procedures, der kan implementere kompleks logik. Anvendes
> serven kun til datastore er det overkill. Her kan Access fx bruges i
stedet
> (el. andre).

Det er jeg ikke enig i, SQL server m.f. understøtter ikke transaktioner, og
dem kan man som regel ikke leve uden ret længe.

Ud over det kan jeg se mange ting som kan laves i f.eks. c++ kode der ikke
kan laves i TSQL.

> I øvrigt understøtter DB2 også stored procedures, hvilke relativt
ubesværet
> kan portes fra SQL Serveren.

Det samme gør Oracle, men jeg syntes ikke det er trivielt at konvertere et
site der er i luften alligevel.


--
Med Venlig Hilsen

Ulrik Lunddahl - nospam037@lunddahl.dk
My heroes: Heddy Lamar & George Antheil

---

"Ulrik Lunddahl" <nospam037@lunddahl.dk> wrote in message
news:ahs7jt$b5q$1@sunsite.dk...
> "Frederik Jensen" <fj@judex.dk> wrote:
>

> > Hvis man anvender SQL Server, synes jeg det vil være ærgeligt hvis man
kun
> > anvender den til datastore. Serveren indeholder mange potente
faciliteter,
> > herunder stored procedures, der kan implementere kompleks logik.
Anvendes
> > serven kun til datastore er det overkill. Her kan Access fx bruges i
> > stede (el. andre).
>
> Det er jeg ikke enig i, SQL server m.f. understøtter ikke transaktioner,
og
> dem kan man som regel ikke leve uden ret længe.

Du mener vel at Access ikke understøtter transaktioner
Svjv så understøtter MSSQL fint transaktioner

> Ud over det kan jeg se mange ting som kan laves i f.eks. c++ kode der ikke
> kan laves i TSQL.
>
Jeg var ikke klar at c++ understøttede set operationer, det er jo netop der
et RDBMS har sin klare force

Ved at undlade at bruge et givent RDBMS stærke sider og holde sig strictly
til fx SQL 89, så kræver det imho også flere muskler for at give en god
performance

De applikationer (middleware) jeg laver i dagligdagen får aldrig brug for
den performance der ligger i de meget store RDBMS installationer, og jeg har
megen glæde af T-SQL og den funktionalitet denne implementering af SQL kan
tilbyde mig

Men det er klart at hvis man forventer at skulle tilbyde sine produkter til
en meget bred kundekreds med særlige behov og skal understøtte mange
forskellige RDBMS så er det værd at overveje at bruge RDBMS som rent
datastorage

mvh/Peter Lykkegaard

---

"Peter Lykkegaard" <polonline@hotmail.com> wrote:

> Du mener vel at Access ikke understøtter transaktioner
> Svjv så understøtter MSSQL fint transaktioner

Ja, jeg skrev bare noget vrøvl. Jeg mente at Access ikke var egnet til andet
en mindre projekter, da den ikke tilbyder særlig god preformance og heller
ikke understøtter transaktioner.


--
Med Venlig Hilsen

Ulrik Lunddahl - nospam037@lunddahl.dk
My heroes: Heddy Lamar & George Antheil

---

"Hans Nielsen" <hn33211___spam@hotmail.com> wrote in message
news:3d3f8379$0$11802$edfadb0f@dspool01.news.tele.dk...
> Er der andre gode/bedre grunde?

Der er blevet nævnt en del gode ting, men en gevinst som også er værd at
tage med er:
At du ved at bruge stored procedure lukker mange muligheder for SQL
Injection da input parametrene har angivet datatyper i modsætning til dine
VBScript variabler i ASP som brugeren kan fylde hvad som helst i.

--
Jakob Andersen