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 / [EMAIL PROTECTED] / http://blog.ianbicking.org _______________________________________________ DB-SIG maillist - [email protected] http://mail.python.org/mailman/listinfo/db-sig
