On Mar 26, 2005, at 10:25 PM, [EMAIL PROTECTED] wrote:
Do all databases need ad hoc query languages?
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.
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 - SQL Queries require complex parsing before data is retrieved
- Results need to be transformed to objects (takes more code and processor time)
- 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.
- Storage requirements may be higher if the tables become sparsely populated.
- If tables are sparsely populated the code for the application will likely have many if/else conditions.
- Good object oriented design is likely to be compromised to make working with a relational database easier.
- Applications with high volumes of data may have to resort to back dooring the data into the database. If you every find yourself in this situation you definitely choose the wrong type of database.
As I stated in previous posts, I'm not against Relational Databases. There is no one type of database that is a silver bullet. They all have their strengths and weaknesses and for the for-seeable future I will continue using the three types. In general I use Relational when I need an ad hoc query language, Embedded when I need to save complex state information, and object orient for the remaining. In some applications I may use 2 or even all 3 types. In some applications where it may be ideal to use 2 or more types I some times make a compromise and use one type if one particular type meets the majority of the application needs well. I also make the compromise for applications that have very simple database needs.
MonetDB <http://monetdb.cwi.nl/> is worth looking at if you're interested in a hybrid model that has the relational database API when you want it, and something lower level and more efficient when you don't. It also supports both the embedded and client/server model, and has some pretty impressive technology behind the scenes.
I haven't done more than play around with it, so I can't personally vouch for it in a production environment, but I sure want to at some point.
(They also support Python out of the box)
-bob
_______________________________________________ DB-SIG maillist - [email protected] http://mail.python.org/mailman/listinfo/db-sig
