On Fri, 27 Apr 2001, you wrote:
> On Fri, Apr 27, 2001 at 09:38:45AM +0100, Robin Szemeti wrote:
> > but of course .. however the topic was (somewhere along the thread)
> > related to portable methods to try and keep from having to change all the
> > SQL between different db version.
> Why do this? Unless you're using the db in a toy capacity (which is
> fair enough: see PHP) it's like using Java when you could be using
> custom DSP hardware.

well somewhere along the thread the topic was keeping your db and app
sorta independent (ala tangram) for the 'we like it .. does it work on
Postgres as well as MySQL' days that come along and you'd rather not
change too much... but agreed for serious heavy duty work a fienly tuned
db schema using the best bits of whatever db you happen to have is the
way to go. 

> [side note: I did just see a bizarre thread in macosx-dev where
> one guy claimed his FFT code was executing faster in Java than C
> because its interpreter used runtime info to optimize it. Search on
> 'informal benchmarks']

uh huh .. but he's a Java programmer .. his C could be *REALLY* bad ;) ..
favourite Java quote 'If javas garbage collector is damn good, how come
the whole thing doesn't delete itself upon execution?'

> > the blocking anly occurs occasionally, ... if you do it sensibly (get all
> > the data ready .. {lock, get max, insert, release}  the lock period is
> > tiny. and not really an issue.
> There are enough assumptions here to make me again suggest you use
> a vendor-specific route :-)

yes .. but the verndor specific code lives in the wrapper class ...

> > however I stll prefer my method (implement it as a 'library' wrapper
> > class on DBI with the appropriate (AUTO_INCREMENT, ROWID, oid, SEQUENCE
> > or whatevr) technique and a library::insert($sql,@args) method) and then
> > you just have to plug in the approprate wrapper between your app and
> > todays choice of DB and in theory the app can stay the same.
> If it was that simple, someone would've done it -- DBI is a very
> mature and competent module. Go check out Automatic Key or Sequence
> Generation in the DBD driver feature summaries and you'll see why
> it's hard to encapsulate this: they're all sooo different.

sure .. but with a wrapper that implements a vendor specific technique
and say  a library_mysql, library_postgres etc I just plug in the
appropriate one between the app and DBI and it works for me ...its just
another layer of (plugable) abstraction.  doesnt seem to slow it down
that much ...
(and if speed was that imoprtant I'd do it in C++[1] anyway :)

[1] .. well except I'm crap at it so it probably wouldnt work .. come to
think of it some of my perl doesnt work .. hmmm.

Robin Szemeti

The box said "requires windows 95 or better"
So I installed Linux!

Reply via email to