---

Hej NG

Det er første gang jeg kigger her i gruppen, så hvis spørgsmålet er åbenlyst
for jer, beklager jeg.

Jeg skal til at udvikle et (i min verden) større webbaseret system, hvor x
antal brugere (op til et par hundrede vel) fra forskellige destinationer på
kloden skal kunne indtaste og læse diverse informationer, som selvfølgelig
skal lagres i en database.
Det skal sandsynligvis kodes i php, og databasen må forventes at kunne blive
meget stor.
Der skal kunne laves grundige søgninger i databasen, så hastighed må være
essentielt.

Informationerne i databasen vil være følsomme, dvs. der skal vel være noget
kryptering (ved ikke om det er relevant).

Eftersom systemet skal kunne sælges til forskellige virksomheder, skal den
være platformsuafhængig (hvis det kan lade sig gøre). Hvordan iøvrigt med
betaling til producenten, hvis man distribuerer databasen med systemerne?

Hvilken database skal man mon bruge?

Mvh
Anders

---

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

"A. Hagstrøm" <hFJERN@gstrom.dk> writes:

> Jeg skal til at udvikle et (i min verden) større webbaseret system,
> hvor x antal brugere (op til et par hundrede vel) fra forskellige
> destinationer på kloden skal kunne indtaste og læse diverse
> informationer, som selvfølgelig skal lagres i en database.

Begyndere bliver ofte overraskede over, at det, de først anser for at
være stort, egentligt kun er legetøjsstørelse for så mange andre.
Da jeg første gang nærmede mig 100 MB, var jeg i hvert fald vældigt
imponeret, men når alt kommer til alt er det ikke så forfærdeligt
meget.

> Det skal sandsynligvis kodes i php, og databasen må forventes at
> kunne blive meget stor.

Definer 'meget stor'. Har du gjort dig klart, hvordan databasen skal
opbygges? Hvis du kan holde de mest centrale tabeller forholdsvist
små, kan andre tabeller sagtens blive vældigt store, uden du behøver
at mærke noget til det.

Lige et advarselsord: hvis der skal betragtelige mængder kode til, vil
jeg advare dig mod at bruge PHP. Det er forrædderrisk let for
begyndere at gå i gang med, men jeg synes hurtigt, det begynder at
lugte fælt, når opgaven vokser. Det gælder i særdeleshed alt, hvad der
hedder fejlhåndtering. Jeg vil anbefale, at du hellere kigger på mere
alsidige højniveausprog som fx Python (min egen favorit), Ruby eller
Perl.

> Der skal kunne laves grundige søgninger i databasen, så hastighed må
> være essentielt.

Hvilken type søgninger? Sandsynligvis vil du have fordel af et
fuldtekstindeks, men sådan et er det da også en overkommelig opgave at
lave, hvis man, som du lyder til, har tænkt sig alligevel at gå i gang
med et større projekt. Jeg mener, at disse dog efterhånden er ved at
være ret udbredte.

I mit speciale arbejdede jeg med databasebaserede søgemaskiner. Hvis
du har brug for det helt store skyts, har jeg noget kode, du kan bygge
videre fra. Ellers vil jeg råde dig til at kigge CiteSeer efter for
referencer til DISCOVER, BANKS og DBXplorer, der alle er sådanne
søgemaskiner. Det er dog meget muligt, at det er at skyde gråspurve
med kanoner.

> Informationerne i databasen vil være følsomme, dvs. der skal vel
> være noget kryptering (ved ikke om det er relevant).

Prøv at spørge lidt nærmere til dette i dk.edb.sikkerhed. Hvilke typer
følsomme oplysninger, er der tale om? Hvis du skal kunne tilgå disse
oplysninger i deres oprindelige form igen, vil det ofte ikke kunne
betale at kryptere dem i databasen. Hvad sikkerhed angår, er databasen
ofte en af de første ting, der bliver brudt ind i, og hvis brugeren
eller du skal kunne tilgå de følsomme oplysninger, kan enhver, der kan
bryde ind i databasen, også tilgå dem, krypterede eller ej. Dette er
stærkt forenklet, men hvis du selv på nuværende tidspunkt havde den
viden og erfaring, der skulle til for selv at lave et system med god
sikkerhed, ville du nok ikke spørge, som du gjorde. Men hvis det
er vigtigt nok, skal du helt sikkert nok få det lært, og
dk.edb.sikkerhed er et godt sted at starte.

> Eftersom systemet skal kunne sælges til forskellige virksomheder,
> skal den være platformsuafhængig (hvis det kan lade sig gøre).

MySQL klarer sig rimeligt godt på Unix og Windows, men halter bagud
med vigtige features, der gør den en reel kandidat på en robust
dataplatform, der kan sikre konsistens i dine data. Det ses især ved,
at sådan noget som transaktioner først for nyligt er blevet klistret
på, og jeg ved ikke engang, om den pt. kan sikre noget så væsentligt
som konsistente fremmednøgler.

PostgreSQL er et væsentligt stærkere alternativ, men den er vist
stadigt mindre heldig på Windows (ustabil, svær at installere). Det
var den i hvert fald engang.

Oracle er et muligt bud, men den koster en hel del og er, har jeg
ladet mig fortælle, et helvede at sætte op.

Firebird? Kender den ikke af andet end navn, men ved, at det er en
mulighed.

MS SQL? Tja, virker selvsagt kun på Windows og koster vist også det
hvide ud af øjnene, dog ikke så meget som Oracle.

Den smarteste løsning er nok at gå efter at udvikle
databaseuafhængigt, så du ret simpelt kan koble dig op til en del
forskellige RDBMS'er. Det er som regel ikke så svært endda.

> Hvordan iøvrigt med betaling til producenten, hvis man distribuerer
> databasen med systemerne?

Det afhænger af DBMS'en. Der er en del, der er Fri Software, så du
frit kan distribuere dem, som du vil. Det gælder i hvert fald MySQL og
PostgreSQL. Oracle og MS SQL har du ingen ret til at distribuere på
nogen måde, med mindre du får en særaftale med firmaerne bag
produkterne, og det tvivler jeg på, at du kan få uden videre.

> Hvilken database skal man mon bruge?

Ja, det er jo ikke så let at svare på, men mit råd er ikke at starte
med MySQL. Den opfordrer ikke til godt design, omend dens ivrige
tilhængere hårdnakket påstår, at de features, den mangler eller har
manglet, er der alligevel ikke nogen, der har brug for. Det er en lang
og kedelig diskussion, men hvis man tager alle de lærebøger, jeg har
set, for gode varer, er MySQL-folkenes argumenter noget tynde. Skal
man dog 'kun' fx lave et webbaseret diskussionsforum eller sådan
noget, er den dog ganske udmærket.


Jeg antager (måske fejlagtigt), at du er begynder hvad angår
databaser, så her er mit bedste råd til dig: læs nogle seriøse bøger
om databaser og teorien bag dem, og få en del praktisk erfaring med
dem, før du kaster dig ud i noget alt for stort. Her taler jeg om
bøger på universitetsniveau, ikke 'Microsoft Access for
Akvariefisk'. At få en god forståelse af relationelle databaser er
svært, før det bliver let, men hvis du sætter dig ind i noget af
teorien bag dem, og samtidigt får noget praktisk erfaring, kommer du
sikkert hurtigt efter det. Ellers kommer du til at begå mange, mange
fejl, og dem skal du alligevel nok komme til at begå nok af. Hvis du
vil gå i gang med at udvikle dit planlagte forsøg, så vær indstillet
på at lave din datainfrastruktur om en hel del gange undervejs. Hvis
ikke du gør det, siger al erfaring, at du vil ende med at fortryde
det.

Den RDBMS, du vælger, kan i øvrigt være så hurtig, det skal være, og
det vil absolut intet betyde, hvis ikke din forståelse af, hvordan
sådanne størrelser er bygget op, er rimeligt fornuftig. Det er primært
i godt design, at man kan gøre sine databaser hurtige og skalerbare i
størrelse. Derefter kan valget af RDBMS naturligvis komme til at
betyde en del, men det er helt klart sekundært.

Martin

- --
Homepage: http://www.cs.auc.dk/~factotum/
GPG public key: http://www.cs.auc.dk/~factotum/gpgkey.txt
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)
Comment: Using Mailcrypt+GnuPG <http://www.gnupg.org>

iEYEARECAAYFAkD8UAoACgkQYu1fMmOQldVX4wCdHPOgzA4NqfS4rGOPNEj9O/bD
vBUAnR7MEMlM7zc1U+nN7EHkge+s7nc+
=uIcI
-----END PGP SIGNATURE-----

---

"Martin Christensen" skrev

> Begyndere bliver ofte overraskede over, at det, de først anser for at
> være stort, egentligt kun er legetøjsstørelse for så mange andre.
> Da jeg første gang nærmede mig 100 MB, var jeg i hvert fald vældigt
> imponeret, men når alt kommer til alt er det ikke så forfærdeligt
> meget.
>
> Definer 'meget stor'. Har du gjort dig klart, hvordan databasen skal
> opbygges? Hvis du kan holde de mest centrale tabeller forholdsvist
> små, kan andre tabeller sagtens blive vældigt store, uden du behøver
> at mærke noget til det.

Jeg kan ikke rigtigt definere meget stor, da det afhænger af brugeren, så
jeg tør ikke sætte tal på. Men det jeg mener er, at der i mange entrys vil
blive indtastet ret lange tekster - sikkert i samme stil som et forum på
internettet. Og jeg ved godt, de tit kører med MySQL .

Jeg har en ide om, hvordan databasen skal opbygges, men slet ikke noget
færdigt. Som du også nævner længere nede, ved jeg først det med sikkerhed
meget senere.

> Lige et advarselsord: hvis der skal betragtelige mængder kode til, vil
> jeg advare dig mod at bruge PHP. Det er forrædderrisk let for
> begyndere at gå i gang med, men jeg synes hurtigt, det begynder at
> lugte fælt, når opgaven vokser. Det gælder i særdeleshed alt, hvad der
> hedder fejlhåndtering. Jeg vil anbefale, at du hellere kigger på mere
> alsidige højniveausprog som fx Python (min egen favorit), Ruby eller
> Perl.

Det er jeg glad for du kommer ind på, for det er præcis den opfattelse jeg
har haft af php, men har fra flere sider fået at vide, at "hvis det bliver
kodet ordentligt" er php fint nok.
Python kender jeg overhovedet ikke, men vil da kigge nærmere på det.

> Hvilken type søgninger? Sandsynligvis vil du have fordel af et
> fuldtekstindeks, men sådan et er det da også en overkommelig opgave at
> lave, hvis man, som du lyder til, har tænkt sig alligevel at gå i gang
> med et større projekt. Jeg mener, at disse dog efterhånden er ved at
> være ret udbredte.
>
> I mit speciale arbejdede jeg med databasebaserede søgemaskiner. Hvis
> du har brug for det helt store skyts, har jeg noget kode, du kan bygge
> videre fra. Ellers vil jeg råde dig til at kigge CiteSeer efter for
> referencer til DISCOVER, BANKS og DBXplorer, der alle er sådanne
> søgemaskiner. Det er dog meget muligt, at det er at skyde gråspurve
> med kanoner.

Nu ved jeg ikke præcis, hvad "fuldtekstindeks" betyder, men hvis du mener at
man skal kunne søge i en hel tekst, har du ret.
Eftersom jeg ikke kender nogle af de ting du nævner, ved jeg ikke om skytset
er for tungt, men jeg vil kigge på det.

> Prøv at spørge lidt nærmere til dette i dk.edb.sikkerhed. Hvilke typer
> følsomme oplysninger, er der tale om? Hvis du skal kunne tilgå disse
> oplysninger i deres oprindelige form igen, vil det ofte ikke kunne
> betale at kryptere dem i databasen. Hvad sikkerhed angår, er databasen
> ofte en af de første ting, der bliver brudt ind i, og hvis brugeren
> eller du skal kunne tilgå de følsomme oplysninger, kan enhver, der kan
> bryde ind i databasen, også tilgå dem, krypterede eller ej. Dette er
> stærkt forenklet, men hvis du selv på nuværende tidspunkt havde den
> viden og erfaring, der skulle til for selv at lave et system med god
> sikkerhed, ville du nok ikke spørge, som du gjorde. Men hvis det
> er vigtigt nok, skal du helt sikkert nok få det lært, og
> dk.edb.sikkerhed er et godt sted at starte.

Ja, det var jo lidt det svar jeg frygtede.
Når jeg skriver "følsomme oplysninger" mener jeg blot, at den virksomhed der
tager systemet i brug sikkert vil putte noget i databasen, som andre ikke må
se. Hvis det er nyttesløst at kryptere en hel database er der jo ikke noget
at gøre ved det.
Og du har helt ret, jeg har ikke arbejdet ret meget med sikkerhed i systemer
før.

> MySQL <snip>
> PostgreSQL <snip>
> Oracle <snip>
> Firebird? <snip>
>MS SQL? <snip>

Udfra, hvad jeg har kunnet læse mig til må man ikke distribuere MySQL med
sit produkt uden at betale for det. Under alle omstændigheder har jeg siden
den oprindelige post blev skrevet, kigget en del på PostgreSQL og synes det
ser fornuftigt ud. Så i første omgang vil jeg satse på det.

> Den smarteste løsning er nok at gå efter at udvikle
> databaseuafhængigt, så du ret simpelt kan koble dig op til en del
> forskellige RDBMS'er. Det er som regel ikke så svært endda.

Også noget jeg har overvejet. Men hvad skulle grunden være, hvis opsætning
af databasen skulle vise sig at være nemt? Foretrækker nogle virksomheder at
bruge deres egen database?

> Jeg antager (måske fejlagtigt), at du er begynder hvad angår
> databaser, så her er mit bedste råd til dig: læs nogle seriøse bøger
> om databaser og teorien bag dem, og få en del praktisk erfaring med
> dem, før du kaster dig ud i noget alt for stort. Her taler jeg om
> bøger på universitetsniveau, ikke 'Microsoft Access for
> Akvariefisk'. At få en god forståelse af relationelle databaser er
> svært, før det bliver let, men hvis du sætter dig ind i noget af
> teorien bag dem, og samtidigt får noget praktisk erfaring, kommer du
> sikkert hurtigt efter det. Ellers kommer du til at begå mange, mange
> fejl, og dem skal du alligevel nok komme til at begå nok af. Hvis du
> vil gå i gang med at udvikle dit planlagte forsøg, så vær indstillet
> på at lave din datainfrastruktur om en hel del gange undervejs. Hvis
> ikke du gør det, siger al erfaring, at du vil ende med at fortryde
> det.

Du tager lidt fejl, men ikke helt.
Jeg er knap færdig som datamatiker og har selvfølgelig arbejdet en del med
relationer og opbygning af tabeller, normalisering osv.
Til gengæld må jeg med pinlig stemme indrømme at den eneste database jeg har
brugt er Access. Derfor uvidenheden omkring andre typer.

At jeg kommer til at begå mange fejl under udviklingen er helt afgjort - det
gør heller ikke noget, sålænge slutproduktet virker som det skal.

> Den RDBMS, du vælger, kan i øvrigt være så hurtig, det skal være, og
> det vil absolut intet betyde, hvis ikke din forståelse af, hvordan
> sådanne størrelser er bygget op, er rimeligt fornuftig. Det er primært
> i godt design, at man kan gøre sine databaser hurtige og skalerbare i
> størrelse. Derefter kan valget af RDBMS naturligvis komme til at
> betyde en del, men det er helt klart sekundært.

Det er klart.

Mange tak for dit lange og grundige svar.
Som sagt synes PostgreSQL lige nu at være et fornuftigt valg, og så vil jeg
kigge nærmere på dine forslag især mht. programmeringssprog.

Mvh
Anders

---

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

"A. Hagstrøm" <hFJERN@gstrom.dk> writes:

>> Definer 'meget stor'. [...]
> Jeg kan ikke rigtigt definere meget stor, da det afhænger af
> brugeren, så jeg tør ikke sætte tal på. Men det jeg mener er, at der
> i mange entrys vil blive indtastet ret lange tekster - sikkert i
> samme stil som et forum på internettet. Og jeg ved godt, de tit
> kører med MySQL .

Du kunne jo beskrive, hvilken type program, du har planer om at lave.
Så kunne det være, at du kunne få et par råd med på vejen.

>> Lige et advarselsord: hvis der skal betragtelige mængder kode til,
>> vil jeg advare dig mod at bruge PHP. [...]
> Det er jeg glad for du kommer ind på, for det er præcis den
> opfattelse jeg har haft af php, men har fra flere sider fået at
> vide, at "hvis det bliver kodet ordentligt" er php fint nok.

'Hvis det bliver kodet ordenligt,' kan man gøre det i assembler,
Brainfuck eller et hvilket som helst andet sprog. De fleste er jo
alligevel Turing-komplette og dermed ækvivalente, så gør det nogen
forskel, hvad man vælger? Bah!

Tilbage i januar lavede jeg et lille hyggeprojekt for nogen i PHP med
MySQL som backend, da det var det, han havde adgang til på sin
server. Det var fælt. Rent subjektivt kan jeg ikke lide syntaksen, men
det er da til at leve med. Scope-reglerne er ret dårligt udtænkte og
tilsyneladende inkonsistente. Klassesystemet er sat på med gaffatape
og hæfteklammer.

Allerværst, hvis du spørger mig, er dog fejlhåndteringen. Jeg kan give
dig et eksempel fra førnævnte hyggeprojekt. Jeg skulle lave en side,
hvor nye brugere kunne oprette konti på pågældende web site. Som hos
de fleste andre sites, skulle brugernavnene være unikke, så hvis det
anmodede brugernavn allerede var optaget, skulle den nye bruger vælge
et nyt. Jeg ville gøre dette ved at forsøge at indsætte den nye
brugers information i en tabel, hvor brugernavnskolonnen naturligvis
er erklæret UNIQUE, og når databasen melder fejl, fordi den ikke kan
indsætte den nye rækker, forventer jeg en exception, som jeg så kan
håndtere ved at fortælle brugeren, at brugernavnet allerede
eksisterer. Men i PHP har man ikke exceptions... man har 'or die':

[kør SQL-kommando] or die [hvis den fejler, gør noget andet]

Problemet er bare, at der kun kan være et enkelt statement, fx til at
udskrive en fejlbesked, efter 'or die'. Det er jo ikke alsidigt på
nogen måde. Resultatet var, at jeg blev nødt til at bruge to queries
til databasen, den første hvor jeg checker, om brugernavnet er
optaget, den anden hvor jeg indsætter den nye brugers data, og det er
grimt som arvesynden, hvis du spørger mig. Dette blev endnu værre i
andre tilfælde, hvor jeg manuelt skulle checke fremmednøglekonsistens,
men er alligevel bare mere af samme skuffe, bare mere omfattende.

> Python kender jeg overhovedet ikke, men vil da kigge nærmere på det.

Sig endeligt til, hvis jeg kan hjælpe med noget. Jeg er vældigt
entusiastisk med dette sprog (selv om det helt klart ikke er
pletfrit), og du ved jo, hvordan vi nørder har det med vore
kæpheste.

Du kan finde masser af information på http://www.python.org. Kort
fortalt er det et (interaktivt) fortolket sprog, runtime-typechecket,
med masser af indbyggede abstrakte datatyper og et stort, solidt
standardbibliotek, 'batteries included'. Det har en del fede
features, som man lynhurtigt kan blive afhængig af, som iteratorer,
list comprehensions og muligheden for at få objekter til at opføre sig
på alle måder som indbyggede typer (fx lister, hashtabeller osv.).

> Nu ved jeg ikke præcis, hvad "fuldtekstindeks" betyder, men hvis du
> mener at man skal kunne søge i en hel tekst, har du ret.

Ja, de bruges til at indeksere tekst med ord, hvor man skal søge på
enkeltstående ord i stedet for mønstre i den fulde tekst (hvilket er
tungt). Nogle sådanne indekser kan også køre 'stemming' på ord,
dvs. reducere ord til deres ordstamme, så 'gnu', 'gnuen' og 'gnuerne'
bliver til samme ord. Nogle gange er det praktisk, nogle gange er det
ikke, men det er altid sprogafhængigt, hvilket man lige skal tænke på.

> Eftersom jeg ikke kender nogle af de ting du nævner, ved jeg ikke om
> skytset er for tungt, men jeg vil kigge på det.

Det er nok ikke lige det første, du har gavn af at kaste dine kræfter
efter. Det kan bedre komme henad vejen.

> Når jeg skriver "følsomme oplysninger" mener jeg blot, at den
> virksomhed der tager systemet i brug sikkert vil putte noget i
> databasen, som andre ikke må se. Hvis det er nyttesløst at kryptere
> en hel database er der jo ikke noget at gøre ved det.

Tja... når vi taler om sådan noget som kundelister osv., der skal være
tilgængelige på et intranet, tror jeg ikke, at du behøver at spekulere
alt for meget over kryptering. Der er jeg sikker på, at de enkelte
firmaer vil have deres egen sikkerhedspolitik, der dækker den slags
ting... ellers er de selv ude om det.

> Udfra, hvad jeg har kunnet læse mig til må man ikke distribuere
> MySQL med sit produkt uden at betale for det.

Er MySQL ikke under to forskellige licenser, GPL og en kommerciel?
GPL-software kan du i hvert fald distribuere, som du vil.

> Under alle omstændigheder har jeg siden den oprindelige post blev
> skrevet, kigget en del på PostgreSQL og synes det ser fornuftigt
> ud. Så i første omgang vil jeg satse på det.

Det er også min favorit.

>> Den smarteste løsning er nok at gå efter at udvikle
>> databaseuafhængigt, så du ret simpelt kan koble dig op til en del
>> forskellige RDBMS'er. Det er som regel ikke så svært endda.
> Også noget jeg har overvejet. Men hvad skulle grunden være, hvis
> opsætning af databasen skulle vise sig at være nemt? Foretrækker
> nogle virksomheder at bruge deres egen database?

Ja, nogle foretrækker at bruge deres egen database. Hvis de allerede
har en kørende RDBMS, er der ingen grund til at sætte en ny op. Det
giver blot mere administration.

>> Jeg antager (måske fejlagtigt), at du er begynder hvad angår
>> databaser, [...]
> Du tager lidt fejl, men ikke helt.
> Jeg er knap færdig som datamatiker og har selvfølgelig arbejdet en
> del med relationer og opbygning af tabeller, normalisering osv.

Det er jo slet ikke så skidt en start.

> Til gengæld må jeg med pinlig stemme indrømme at den eneste database
> jeg har brugt er Access. Derfor uvidenheden omkring andre typer.

Kan du så se at få noget jord under neglene! Hvis du begynder med
PostgreSQL, kan jeg anbefale Bruce Momjians 'PostgreSQL: Introduction
and Concepts' (http://www.postgresql.org/docs/awbook.html), som også
giver en god praktisk introduktion til brug af relationelle databaser
generelt.

Martin

- --
Homepage: http://www.cs.auc.dk/~factotum/
GPG public key: http://www.cs.auc.dk/~factotum/gpgkey.txt
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)
Comment: Using Mailcrypt+GnuPG <http://www.gnupg.org>

iEYEARECAAYFAkD+ZGwACgkQYu1fMmOQldW39gCgn7nfKCWELiVF2+MaMZ8B5cjJ
f90AnR4TO/og914TDN//E1mgdR0yRi7M
=OPH/
-----END PGP SIGNATURE-----

---

"Martin Christensen" wrote ¨
>
[Snip - MySQL/PHP]

> Jeg ville gøre dette ved at forsøge at indsætte den nye
> brugers information i en tabel, hvor brugernavnskolonnen naturligvis
> er erklæret UNIQUE, og når databasen melder fejl, fordi den ikke kan
> indsætte den nye rækker, forventer jeg en exception, som jeg så kan
> håndtere ved at fortælle brugeren, at brugernavnet allerede
> eksisterer. Men i PHP har man ikke exceptions... man har 'or die':
>
Hmm, nu er det sjældent en god ting at basere sig på exceptions
Det stjæler af performance

Hvis du nu havde brugt RDBMS der understøtter flere statements i samme hug
så kunne du jo checke for din key og indsætte hvis den ikke fandtes eller
returnere et fejlnummer/text hvis der var et problem, very svelegant
Det samme med ex insert eller update i samme kald etc

- Peter

---

Martin Christensen wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
[snip]
>>>Lige et advarselsord: hvis der skal betragtelige mængder kode til,
>>>vil jeg advare dig mod at bruge PHP. [...]
>>
>>Det er jeg glad for du kommer ind på, for det er præcis den
>>opfattelse jeg har haft af php, men har fra flere sider fået at
>>vide, at "hvis det bliver kodet ordentligt" er php fint nok.
>
>
> 'Hvis det bliver kodet ordenligt,' kan man gøre det i assembler,
> Brainfuck eller et hvilket som helst andet sprog. De fleste er jo
> alligevel Turing-komplette og dermed ækvivalente, så gør det nogen
> forskel, hvad man vælger? Bah!
>
> Tilbage i januar lavede jeg et lille hyggeprojekt for nogen i PHP med
> MySQL som backend, da det var det, han havde adgang til på sin
> server. Det var fælt. Rent subjektivt kan jeg ikke lide syntaksen, men
> det er da til at leve med. Scope-reglerne er ret dårligt udtænkte og
> tilsyneladende inkonsistente. Klassesystemet er sat på med gaffatape
> og hæfteklammer.

Nok meget individuelt. Jeg kan kan godt lide syntaksen, fordi den ligner
alle de andre C-lignende sprog. Hvis man er vant til C, C++, Java eller
C# er det et stort plus.

Scope-reglerne er lidt anderledes, men jeg kan ikke forstå du synes de
er dårligt udtænkte eller inkonsistente. Er det brug af "global" du
tænker på?



> Allerværst, hvis du spørger mig, er dog fejlhåndteringen. Jeg kan give
> dig et eksempel fra førnævnte hyggeprojekt. Jeg skulle lave en side,
> hvor nye brugere kunne oprette konti på pågældende web site. Som hos
> de fleste andre sites, skulle brugernavnene være unikke, så hvis det
> anmodede brugernavn allerede var optaget, skulle den nye bruger vælge
> et nyt. Jeg ville gøre dette ved at forsøge at indsætte den nye
> brugers information i en tabel, hvor brugernavnskolonnen naturligvis
> er erklæret UNIQUE, og når databasen melder fejl, fordi den ikke kan
> indsætte den nye rækker, forventer jeg en exception, som jeg så kan
> håndtere ved at fortælle brugeren, at brugernavnet allerede
> eksisterer. Men i PHP har man ikke exceptions... man har 'or die':
>
> [kør SQL-kommando] or die [hvis den fejler, gør noget andet]

Ved ikke lige hvor du har det fra, men exceptions og det at man skriver
"or die" efter et udtryk kan på ingen måde sammenlignes.

"or" kan bruges fordi fortolkeren optimerer behandling af logiske
udtryk, så "die" bliver kun udført hvis det første udtryk returnerer en
værdi der evalueres som falsk.

funkA() or funkB();

er bare en kortere form af

if ( ! funkA() ) {
funkB();
}


> Problemet er bare, at der kun kan være et enkelt statement, fx til at
> udskrive en fejlbesked, efter 'or die'. Det er jo ikke alsidigt på
> nogen måde. Resultatet var, at jeg blev nødt til at bruge to queries
> til databasen, den første hvor jeg checker, om brugernavnet er
> optaget, den anden hvor jeg indsætter den nye brugers data, og det er
> grimt som arvesynden, hvis du spørger mig. Dette blev endnu værre i
> andre tilfælde, hvor jeg manuelt skulle checke fremmednøglekonsistens,
> men er alligevel bare mere af samme skuffe, bare mere omfattende.

Jeg kan godt se du har haft det besværligt, men det er næppe php's fejl
at du har brugt en lidt bøvlet konstruktion.
Det er nok meget upædagogisk at det bliver brugt i eksempler i
php-manualen på php.net


X og FollowupTo: news:dk.edb.internet.webdesign.serverside.php

/Bent

---

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

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

> Hmm, nu er det sjældent en god ting at basere sig på exceptions Det
> stjæler af performance

Ja puha, måske et helt mikrosekund hver gang man opretter en ny
bruger! Så er det jo helt klart bedre med nogle flere SQL statements.
Det må da helt klart være billige at fortolke et sådant statement,
udføre en plan for dets udførsel, låse hvor relevant og muligvis at
skulle en ekstra tur eller tre på harddisken.

> Hvis du nu havde brugt RDBMS der understøtter flere statements i
> samme hug så kunne du jo checke for din key og indsætte hvis den
> ikke fandtes eller returnere et fejlnummer/text hvis der var et
> problem, very svelegant

En af DBMS'ens vigtigste opgaver er at varetage mine datas
integritet. Jeg har meget svært ved at se det 'svelegante' i, at
programmøren nu pludseligt skal til at varetage denne opgave
eksplicit, og desuden huske at gøre dette alle steder, hvor det er
relevant, hvor den slags typisk kun skal gøres én gang i DBMS'en.

Martin

- --
Homepage: http://www.cs.auc.dk/~factotum/
GPG public key: http://www.cs.auc.dk/~factotum/gpgkey.txt
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)
Comment: Using Mailcrypt+GnuPG <http://www.gnupg.org>

iEYEARECAAYFAkD+mLYACgkQYu1fMmOQldUdmgCfUti3jGsTJ1WMreKk3Q3bYHWA
9uQAoKESDMtZeyhaara7fAx9LzaUdwPS
=h0I4
-----END PGP SIGNATURE-----

---

"Martin Christensen" wrote

> En af DBMS'ens vigtigste opgaver er at varetage mine datas
> integritet. Jeg har meget svært ved at se det 'svelegante' i, at
> programmøren nu pludseligt skal til at varetage denne opgave
> eksplicit, og desuden huske at gøre dette alle steder, hvor det er
> relevant, hvor den slags typisk kun skal gøres én gang i DBMS'en.
>
Prøv at læse Kristians svar i tråden MSSQL: Views vs. Stored Procedures
2c9e2992.0407191113.6f2d89a0@posting.google.com

Det dækker vist ret godt hvad jeg har i tankerne

- Peter

---

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

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

> Prøv at læse Kristians svar i tråden MSSQL: Views vs. Stored
> Procedures 2c9e2992.0407191113.6f2d89a0@posting.google.com
>
> Det dækker vist ret godt hvad jeg har i tankerne

Råb lige op, hvis jeg misforstår noget, men jeg kan altså stadigt ikke
se, at jeg har vundet noget. Den opgave, jeg forventer, at DBMS'en
varetager, er at den beskytter dataintegriteten ved at melde fejl, når
jeg forsøger at indsætte ugyldige data. Fejlen skal under alle
omstændigheder håndteres i det kode, der vil indsætte pågældende data,
det kommer vi ikke udenom.

Så vidt jeg kan se, gør dit forslag den forskel, at jeg i databasen
kan kode til en procedure, som kan indsætte data, hvis det er
gyldigt, og ellers melde fejl. Denne opførsel forventer jeg i forvejen
af min DBMS, og hvis den gør mindre, føler jeg mig snydt.

Hvad angår håndtering af fejl i den kaldende kode angår, forestiller
jeg mig, at forskellene er som følger:

/* Som jeg gerne vil have det */
try:
indsæt data
catch:
håndter fejlsituationen

/* Som jeg forstår dit alternativ */
resultat = indsæt data
if resultat == fejl:
håndter fejlsituationen
else:
måske noget her, måske ikke

Det kan nok med rette påstås, at de to i praksis ikke er så
forskellige, men æstetisk og forståelsesmæssigt synes jeg klart bedst
om første alternativ. Der er det helt klart, hvad der er normal, og
hvad der er særlig opførsel for programmet. Desuden er første metode
væsentligt mere fleksibel, når der skal håndteres flere fejlklasser
(dvs. der smides forskellige exceptions). Hvis fx jeg ikke kan få
forbindelse til DBMS'en, håndteres denne fejl på lige linie med, men
adskilt fra, fejl ved indsætning af data. Anden metode bliver nødt til
at checke for den slags separat, og skal der checkes for nok
forskellige ting, kan det give ret dybe nestede if'er.

Næh tak, lad mig beholde mine exceptions!

Martin

- --
Homepage: http://www.cs.auc.dk/~factotum/
GPG public key: http://www.cs.auc.dk/~factotum/gpgkey.txt
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)
Comment: Using Mailcrypt+GnuPG <http://www.gnupg.org>

iEYEARECAAYFAkD+3m0ACgkQYu1fMmOQldV7FgCg6EOjQhv8cBlNepmj9ffXmoA1
9ucAnAv2ARoF9DfyfK9rFbDK1GFiz0Bw
=/7lv
-----END PGP SIGNATURE-----

---

"Martin Christensen" wrote

> Råb lige op, hvis jeg misforstår noget, men jeg kan altså stadigt ikke
> se, at jeg har vundet noget. Den opgave, jeg forventer, at DBMS'en
> varetager, er at den beskytter dataintegriteten ved at melde fejl, når
> jeg forsøger at indsætte ugyldige data. Fejlen skal under alle
> omstændigheder håndteres i det kode, der vil indsætte pågældende data,
> det kommer vi ikke udenom.

Prøv at forestille dig en situation hvor du nogle data hvor du faktisk
ikke helt er klar om nøglen eksisterer i forevejen
Eller en anden situation hvor du skal indsætte fx en header og et antal
linier i en underliggende tabel
Med tilhørende tjek af utallige parametre

En mulighed er at lade rdbms om det hele og efterfølgende få en kode
tilbage der så trigger en meddelelse til brugeren
En anden mullighed at at sætte en række klasser i mellem rdbms og
brugeren hvor din forretningslogik er placeret, det vil man gøre hvis
man skal bruge forsk rdbms

> Så vidt jeg kan se, gør dit forslag den forskel, at jeg i databasen
> kan kode til en procedure, som kan indsætte data, hvis det er
> gyldigt, og ellers melde fejl. Denne opførsel forventer jeg i forvejen
> af min DBMS, og hvis den gør mindre, føler jeg mig snydt.
>
Tjohh, men så skal du jo igang med at tjekke for SQL injections før du
kommer i nærheden af databasen
Ved at sende nogle parametre efter dit rdbms i stedet for hele din
statement så bliver den risiko jo fuldstændig elimineret
NB! Det er ikke nødvendig med SP's for at implementere dette

Jeg bruger command objectet i .NET
Perl har sin egen måde at håndtere dette på
Og muligvis kan PHP også håndtere dette hvis ens rdbms understøtter det

> Hvad angår håndtering af fejl i den kaldende kode angår, forestiller
> jeg mig, at forskellene er som følger:
>
> /* Som jeg gerne vil have det */
> try:
> indsæt data
> catch:
> håndter fejlsituationen

Kunne ligne Java eller .NET til forveksling
>
> /* Som jeg forstår dit alternativ */
> resultat = indsæt data
> if resultat == fejl:
> håndter fejlsituationen

Jow "fejlsituation" kan så være en anden klasse der håndtere alt vedr
fejl

> else:
> måske noget her, måske ikke
>
hvorfor else?
Du har jo ikke en tilsvarende blok i din try/catch?

> Det kan nok med rette påstås, at de to i praksis ikke er så
> forskellige, men æstetisk og forståelsesmæssigt synes jeg klart bedst
> om første alternativ. Der er det helt klart, hvad der er normal, og
> hvad der er særlig opførsel for programmet. Desuden er første metode
> væsentligt mere fleksibel, når der skal håndteres flere fejlklasser
> (dvs. der smides forskellige exceptions). Hvis fx jeg ikke kan få
> forbindelse til DBMS'en, håndteres denne fejl på lige linie med, men
> adskilt fra, fejl ved indsætning af data.

Forbindelse til databasen og selve brug af databasen et to forsk ting og
behandles af to forsk klasser
Den fejlkode der kommer tilbage fra rdbms giver jo en præcis afgrænsning
af fejlårsagen og rapportering håndteres samlet andetsteds fejlkoden
skal bare sendes videre i systemet

> Anden metode bliver nødt til
> at checke for den slags separat, og skal der checkes for nok
> forskellige ting, kan det give ret dybe nestede if'er.
>
Som jeg ser har du en del gentagende exceptions strøet ud med rund hånd?

> Næh tak, lad mig beholde mine exceptions!
>
Jow jow, det er jo dybest set to forskellige ideologier

- Peter

---

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

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

> Prøv at forestille dig en situation hvor du nogle data hvor du
> faktisk ikke helt er klar om nøglen eksisterer i forevejen

Hvad er problemet? Hvis jeg har til hensigt at indsætte dataene, hvis
de er gyldige, så har jeg tænkt mig at forsøge at indsætte dem, og
forventer en fejl, hvis det ikke lader sig gøre. Det er da den normale
fremgangsmåde. Hvis jeg uafhængigt af indsættelse af data er
interesseret i, om en bestemt nøgle eksisterer, så er det
selvfølgeligt en anden sag.

> Eller en anden situation hvor du skal indsætte fx en header og et
> antal linier i en underliggende tabel

Jeg forstår ikke, hvad du mener.

> Med tilhørende tjek af utallige parametre

Check af parametre bør høre til i databasen. Den skal sikre, at
dataene ikke kan blive inkonsistente.

> En mulighed er at lade rdbms om det hele og efterfølgende få en kode
> tilbage der så trigger en meddelelse til brugeren
> En anden mullighed at at sætte en række klasser i mellem rdbms og
> brugeren hvor din forretningslogik er placeret, det vil man gøre
> hvis man skal bruge forsk rdbms

Jeg forstår ikke din pointe. Min egen oprindelige pointe var såmænd
bare, at jeg ikke er begejstret for ideen om at skulle behandle fejl
eller særlige hændelser, som andet, end hvad de er.

>> Så vidt jeg kan se, gør dit forslag den forskel, at jeg i databasen
>> kan kode til en procedure, som kan indsætte data, hvis det er
>> gyldigt, og ellers melde fejl. Denne opførsel forventer jeg i
>> forvejen af min DBMS, og hvis den gør mindre, føler jeg mig snydt.
> Tjohh, men så skal du jo igang med at tjekke for SQL injections før
> du kommer i nærheden af databasen
> Ved at sende nogle parametre efter dit rdbms i stedet for hele din
> statement så bliver den risiko jo fuldstændig elimineret
> NB! Det er ikke nødvendig med SP's for at implementere dette

Øh... er du ikke klar over, at man også kan lave parameteriserede
forespørgsler? Det sikrer også mod SQL injections. Det er efterhånden
ret godt understøttet.

>> /* Som jeg gerne vil have det */
>> try:
>> indsæt data
>> catch:
>> håndter fejlsituationen
>
> Kunne ligne Java eller .NET til forveksling

Nu er .NET jo ikke et programmeringssprog...

>> /* Som jeg forstår dit alternativ */
>> resultat = indsæt data
>> if resultat == fejl:
>> håndter fejlsituationen
>
> Jow "fejlsituation" kan så være en anden klasse der håndtere alt
> vedr fejl

Den skal stadigt kodes. Det bliver ikke nødvendigvis pænere eller mere
overskueligt af, at man uddelegerer opgaven til en separat klasse
eller funktion. Og nu er alt jo ikke nødvendigvis klasser.

>> else:
>> måske noget her, måske ikke
>>
> hvorfor else?
> Du har jo ikke en tilsvarende blok i din try/catch?

Nej, ikke eksplicit, men tænk flere catch statements.

> Forbindelse til databasen og selve brug af databasen et to forsk
> ting og behandles af to forsk klasser

Hvorfor er det nødvendigvis sagen?

> Den fejlkode der kommer tilbage fra rdbms giver jo en præcis
> afgrænsning af fejlårsagen og rapportering håndteres samlet
> andetsteds fejlkoden skal bare sendes videre i systemet

Ja, den skal sendes videre... _eksplicit_. Endnu et point til
exceptions: de lader sig propagere ganske gratis ved, at man blot
undlader at fange dem.

>> Anden metode bliver nødt til at checke for den slags separat, og
>> skal der checkes for nok forskellige ting, kan det give ret dybe
>> nestede if'er.
> Som jeg ser har du en del gentagende exceptions strøet ud med rund
> hånd?

Din pointe?

>> Næh tak, lad mig beholde mine exceptions!
> Jow jow, det er jo dybest set to forskellige ideologier

Tjo, jeg er så mageligt doven, at jeg foretrækker, at maskinen laver
så meget arbejde som muligt for mig, og abstraktioner som fx
exceptions er blot en af de mange ting, der hjælper i den retning. Jeg
vil fx også meget hellere bruge invarianter, præ- og postbetingelser,
der er inkorporeret i mit programmeringssprog, end jeg vil strø om mig
med assertions eller - gys - tilsvarende if-sætninger.

Martin

- --
Homepage: http://www.cs.auc.dk/~factotum/
GPG public key: http://www.cs.auc.dk/~factotum/gpgkey.txt
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)
Comment: Using Mailcrypt+GnuPG <http://www.gnupg.org>

iEYEARECAAYFAkD/2vkACgkQYu1fMmOQldVJRACfehm8WHh/DxUO0wpB5ev/OkIf
F7AAnjrM0eLFRB/gYC3jKXULbQcPVp0j
=LcRw
-----END PGP SIGNATURE-----