🚀 go-pugleaf

Vincent WILLEMS <vincent.willems@work-it-out.com> wrote:
> Philip Paeps <philip@paeps.cx> wrote:
> > Vincent WILLEMS <vincent.willems@work-it-out.com> wrote:
> > > Philip Paeps <philip@paeps.cx> wrote:

[...]

> > > > Het komt neer op modularisatie.  Als je database parameters gaat
> > > > hardcoden (in *any* language) maak je er een soep van.  Als je ADO,
> > > > DAO of andere prutsjes gebruikt, ben je platform-afhankelijk.
> > > > (Open)ODBC is tergend traag.
> > >
> > > Misschien interessant om eens te lezen:
> > > http://ourworld.compuserve.com/homepages/Ken_North/API_test.htm
> >
> > Boeiend.  Dat artikel is ondertussen meer dan zeven jaar oud.

[...]

> Artikel is inderdaad vrij oud, 't komt uit Dr. Dobbs; er is in de tussentijd
> wel al heel wat veranderd, denk maar aan connection pooling, parameter
> binding, etc. die de performantie alleen maar naar boven kan halen!

Inderdaad.

De native APIs zijn er de laatste paar jaar *serieus* op vooruit gegaan,
vooral die van OpenSource databases dan (ik denk vooral aan PostgreSQL, die
gebruik ik het meest), maar ook DB2 en Sybase zijn serieus ge�volueerd.

Ik vermoed dat OpenODBC ook wel wat veranderd is, maar ik blijf toch liever
bij de gewone APIs.

> Ik ben niet pro 't een of pro 't ander (ook niet uitgesproken voor Unix,
> Linux, FreeBSD, Microsoft, noem maar op), maar ODBC is onder Microsoft (en
> dus nu ook bvb. onder Linux) een heel makkelijk middel om een applicatie te
> schrijven, zonder dat je op voorhand weet welke database er gebruikt zal
> worden. Jouw wrapper verhaal is een oplossing, maar zoals je zei, er dient
> gelinkt te worden met de native API's. 

Je weet dan wel op voorhand dat je die API-libraries moet meeleveren.  Je weet
niet op voorhand of je client OpenODBC op zijn systeem staan heeft, en da's
nogal een log beest om mee te geven.

> Bij ODBC volstaat het dat er een driver is en bovendien kan van de ene op de
> andere dag zonder hercompileren of whatever een andere database gebruikt
> worden. Dit voordeel (en andere) is zeker een van de redenen van het bestaan
> van dingen zoals o.m. UnixODBC.

Van database veranderen kan met modulaire code ook van de ene dag op de andere
zonder hercompileren.  Als je tenminste je applicatie niet statisch met je
database-wrapper gelinkt hebt.  Je vervangt gewoon je wrapper library door een
andere, en zorgt er uiteraard voor dat de calls dezelfden blijven.

> Daarnaast niet onbelangrijk, platform-onafhankelijkheid is er, want de ODBC
> code is dezelfde voor UNIX & Microsoft...

Voor mij is dat geen voordeel.  Ik schrijf geen code voor Microsoft.

Normaal kan mijn code zonder problemen op alle platformen die een beetje
POSIX-compliant zijn compilen.  Enige vereiste is dat er een database API voor
het bewuste platform bestaat.  De PostgreSQL API is Open en compilet ook op
zowat alle platforms, aldaniet met wat massage.

Ik test doorgaans mijn code op i386, alpha en sparc64.  Toch de meest
'populaire' platforms voor database-clients.  Als code op m68k moet werken,
zal ik die daar wel specifiek voor schrijven :-P

> > Wil je alsjeblieft ook eens de settings van je newsreader nakijken?  Die
> > helpt linebreaks finaal om zeep, en wrapt op een hoogst idiote manier.
> > Niet iedereen heeft een gq operator om zo'n rommel op te ruimen.
> 
> Outlook Express standaard ingesteld

'Standaard' stuurt die dingen dan grondig in de soep.  Ik heb weer alles
moeten rewrappen.  Oh well.  Gq helpt, maar het blijft lastig.

 - Philip

-- 
Philip Paeps                                                   philip@paeps.cx

  Cop-out number 1.
  You should have seen it when I got it.