[DB-SIG] Re: [Pycon2005-attendees] Pycon2005 and database divide (ODB vs relational DB)

[Ian Bicking]

john.m.camara at comcast.net wrote:
> Do all databases need ad hoc query languages?

A single language, no, but I do think they all need good support for ad 
hoc queries.  If I have to change my persistent data model to 
efficiently and consistently query the objects (or tuples) in a new way, 
then that model is too fragile.

As for languages -- most ad hoc queries could be expressed as list 
comprehension (maybe evil nested list comprehensions), but that's 
hopelessly inefficient so it wouldn't really do, which is really to say 
that the imperative approach to queries doesn't work.  Python doesn't 
have great support for creating queries without executing them -- you 
can kind of do it, and it's not terribly hard, but it's kind of a hack 
of the Python syntax and a bit confusing.  This probably leads to a 
"language" -- but in another programming language (like Lisp) a query 
might not seem so unnatural and might not even be seen as a separate 
language at all.

> Oh, I can already feel the heat is on its way before I even get the
> words typed out.
> 
> IMHO, saying or believing a database needs an ad hoc query language
> is equivalent to saying or believing a language needs static types.

Perhaps so, but that argument goes both ways.  People use static typing 
as a technique to control complexity (and static proponents say that 
dynamic typing is only appropriate for simple projects).  But static 
typing is one technique among many to control complexity, and if we can 
leverage dynamic typing to control complexity in other ways then it 
could be a better way to approach problems.

Ad hoc queries are a kind of future protection, so that as the way you 
use data changes you can facilitate that efficiently without changing 
your data model.  Maybe you can manage a way to change your data model 
with less cost than in a relational database... but that's a pretty hard 
problem.  But to argue that this kind of future protection isn't 
necessary for all projects is only to say that object databases are only 
useful for small projects or disposable data... which probably isn't 
your argument.

> All Relational Databases lovers should now take a couple of slooooow
> deep breaths and cool down.
> 
> There are quite a few object oriented applications that require only
> querying over a relatively few fields and thus does not need the
> flexibility that SQL provides.  If such an application uses a
> Relational Database it will come with some costs.
> 
> - Query are slower 

Sometimes, though of course other queries are faster because of the 
abstract and well optimized query engine.

> - SQL Queries require complex parsing before data
> is retrieved

A flaw of SQL, not an RDBMS.

> - Results need to be transformed to objects (takes more
> code and processor time)

True, but this will be true of any language-neutral database.

> - Refactoring the Application is harder and
> more error prone as changes need to be done in many places (object
> model, relational mapping, database, etc).  Just like the good old
> procedural days when you had to remember to make changes scattered
> through out the code base.

Hmm... this I don't understand.  Ad hoc queries should *isolate* changes 
to the places where you use specific queries.  They are not in 
themselves a method of abstraction, but you can still achieve that 
abstraction on top of those queries.  Efficiently implementing a new 
type of query without the relational mechanisms itself can lead to many 
more significant changes to your code.

> - Good object oriented design is likely to be compromised
> to make working with a relational database easier. 

Eh... maybe that's a feature to me ;)  I'm not a fan of OO design, 
insofar as design being good because it is OO.  Typically OO has a place 
in a good design, but I seldom think it's right to start with ideas like 
classes and inheritance when considering design.

-- 
Ian Bicking  /  ianb at colorstudy.com  / http://blog.ianbicking.org