Date: Tue, 13 Jan 2004 00:24:12 +0900
From: “Weirich, James” James.Weirich@FMR.COM
Newsgroups: comp.lang.ruby
Subject: Re: Database applications and OOness
right. but every dbms binding has a different basic api. Why this useless
duplication? (Probably that may be useful, and I’m just too stupid to
understand why)
(to above OP)
consider how a F1 car would drive if it were made to have the same ‘interface’
as a 1970 volkswagon beetle…
the problem with this approach is that you are stuck with
a) a ‘least common denominator’ type approach, and lose the feature that
distinguish some db’s as better for certain types of things that others
b) an api which conditionally offers some calls, leaving them empty for some
dbs. IMHO this is plain confusing as only a tiny, tiny, tiny bit better
than simply learning the appropriate apis
in otherwords, if your ‘car’ has 7 gears and afterburners - you need an ‘api’
to access them! if your car is an automatic, you should not have a ‘clutch’
method…
I’ll try to explain some of the rationale behind the DBI implementation.
First, let’s examine the layers involved.
The DBMS API layers is provided by the DBMS itself. This is generally a C
language API that must be adapted to Ruby through a library.
Ruby-postgres-0.7.1 is such a library. It adapts the PostgreSQL C API to
Ruby. There are similar libraries for other DBMS. Sometimes the API is
wrapped in a thin OO veneer. Sometimes additional functionality beyond the
C API is provided.
The DBD level uses the native API to provide a standard DB protocal to the
rest of the DBI code. If a Ruby-callable version of a native API didn’t
exist, then the DBD would have to be written (at least in part) in C.
Finally, the DBI level contains the common code used to implement the
abstract DBI interface.
Can a user use the DBD directly and skip a level? Yes, but I don’t think
they will find the DBD interface nearly as nice to use as the DBI interface.
Could the DBD and native interfaces be merged? Yes. In fact, I would
encourage those who provide a native DBMS interface to consider providing a
DBD interface as well. This would be similar to the Java world where it is
generally the responsibility of the DBMS vender to supply the JDBC drivers.
Could the DBI and DBD levels be merged? Yes, but that would require each
DBD to duplicate a lot of code that exists in the DBI, obviously not a good
thing. Also, a merged DBI/DBD level would be much more difficult for a
vender to supply than a relatively straight-forward DBD library. I think it
remains a good idea to keep the DBD and DBI separate.
If you are into design patterns, it is worth noting that the DBI
implementation is a simplified version of the Bridge Pattern (simplified in
that we don’t normally subclass any of the DBI classes). It also bears a
strong resemblance to the Strategy Pattern.
I hope this helps explain some of the rational behind the DBI
implementation.
i think the strength of patterns stems from the fact that they abstract
difficult things into managable chunks in a proven way. i have always felt
that database usage is not an appropriate application of such abstractions:
databases are simply not that difficult to use and it is essentially only
certain aspects of them which can be abstracted. several people i work with
swear by perl/ruby/java dbi/jdbc. they seem to be constantly struggling with
even the most basic database operations and tracking sublte bugs stemming from
the ‘little’ differences in db implimentations. to convice yourself of this
just do a search of dbi vs., say, postgres bugs/usage problems on c.l.r. or,
ask yourself why all the vendors cannot simply abide by the SQL standards? if
they cannot seems to make it work - perhaps there is a reason?
in addition, i think that few projects place the proper weight on database
design - pushing far too much logic into the application - and abstractions
such as dbi encourage this type of thinking (or lack of): databases are all
the same right?. IMHO one really needs to sit down and consider a design
quite carefully in the context of the available db options - at that point one
will clearly emerge as the ‘better’ db in most situations due to feature ‘x’;
in otherwords, it is the differences between dbs that make them valuable
(consider postgresql vs. sqlite vs. pstore) - not the similarities.
i know of projects which have chosen to utilize mysql because: ‘it is fast’.
then proceed to access it via layer upon layer of apis - doing nothing but
simple searches. the funny thing is, the application really does need to be
fast - the not so funny thing is that by simply cutting to the chase and using
berkley db directly (which is all mysql is doing in this case) enormous speed
gains could be realized. of course, this seems to too ‘hard’ since one need
learn a new api - but when really nice interfaces like guy’s bdb interface
exist it is simply not all that tough:
db[large_object.key] = Marshal.dump large_object
i suppose what i am saying is that i generally oppose trying to cram dbs into
the same box. i feel that, by giving the impression that all dbs are that
same, abstractions like jdbc encourage bad design and bad programming.
not trying to start a flame war, just my 2 cents. 
-a
···
On Tue, 13 Jan 2004, Weirich, James wrote:
ATTN: please update your address books with address below!
===============================================================================
EMAIL :: Ara [dot] T [dot] Howard [at] noaa [dot] gov
PHONE :: 303.497.6469
ADDRESS :: E/GC2 325 Broadway, Boulder, CO 80305-3328
STP :: Solar-Terrestrial Physics Data | NCEI
NGDC :: http://www.ngdc.noaa.gov/
NESDIS :: http://www.nesdis.noaa.gov/
NOAA :: http://www.noaa.gov/
US DOC :: http://www.commerce.gov/
The difference between art and science is that science is what we
understand well enough to explain to a computer.
Art is everything else.
– Donald Knuth, “Discover”
/bin/sh -c ‘for l in ruby perl;do $l -e “print "\x3a\x2d\x29\x0a"”;done’
===============================================================================
