> 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.