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. John > Peter Mott wrote: > > I always understood that the weakness of Object Databases was that they > > provided no general ad hoc query language like SQL (or QUEL) though there > > was no a priori reason why they couldn't. The way relational databases were > > grounded in 1st order predicate logic (FOPC) seemed to give them an > > advantage which Object Databases despite announcements and languages to the > > contrary never quite manageed to overcome. I do know that the Relational > > Model is based on the logic of Frege (1879), the predicate logic, while the > > object model harks back to the IS_A hierarchies underpinning the logic of > > Aristotle (300 BC). I checked out the orbtech URL but found nothing about > > languages, logic or even taxonomies. So give us more evidence that the world > > has changed! It has been long announced but has not happened. Frege rules. > > The proof is in the pudding. There is much misinformation in the world > and especially in the academic publications on this topic. I don't have > the time or interest in correcting that. I want to build tools that > work. Other people can follow up with the theory about why they work. > I've already read too many theoretical papers that said what I've > already done with Schevo couldn't be done. Never piss off an Irishman > by telling him something can't be done. He might just go and do it > anyway. ;-) > > -- > Patrick K. O'Brien > Orbtech http://www.orbtech.com > Schevo http://www.schevo.org > Pypersyst http://www.pypersyst.org > > _______________________________________________ > Pycon2005-attendees mailing list > [EMAIL PROTECTED] > http://mail.python.org/mailman/listinfo/pycon2005-attendees _______________________________________________ DB-SIG maillist - [email protected] http://mail.python.org/mailman/listinfo/db-sig
