> A) a ridiculously flexible interface that looks sort of like SQL, except
> where it is SQL, except where it's only sort of like SQL, etc.
>
> B) a ridiculous profusion of classes, methods, or both.
>
> SQL has its place, and Alzabo merely provides a thin layer on top of it.
>
> Trying to jam a thick layer of OO-goodness over relational data is asking
> for a mess. OO has its place, but if your application is primarily about
> the database, I don't think that a heavy OO layer on top of that will do
HI Dave,
Totally agree.
My general motto is "tiers eq tears" ... I've never seen
a really comfortable OO/SQL bridge.
The OO part almost always dumbs down or hobbles the database.
Group bys, order bys, multi-table selects, locking, SQL query
plans and index optimisation all rightfully belong to the database but are
an anathema to a simple OO/SQL bridge.
While disks need to seek and spin ... relational databases will
have their place. I sometimes think of a world with unlimited RAM. It's
here that OO dreams really come true --- vast pools of objects with
hash/array look up speed etc.
Until that time though ... I personally code with the database
foremost in my mind - and disk seeks a close second - for me the SQL comes
first and so I have no problem with large <<HEREDOCs of SQL in my code.
Generally I try to minimise the layers/tiers/abstraction between
the front-end and the database - for me OO/SQL abstraction is something
akin to 'GOTO considered harmful'.
Nige
Nigel Hamilton
Turbo10 Metasearch Engine
email: [EMAIL PROTECTED]
tel: +44 (0) 207 987 5460
fax: +44 (0) 207 987 5468
________________________________________________________________________________
http://turbo10.com Search Deeper. Browse Faster.
