Re: Object-oriented Databases

> One of the major points against OODBMS is the need to report against 
> the DB in an ad-hoc fashion. Lets say you develop an application 
> successfully using OODBMS perfectly against known requirements and 
> deploy it successfully into production. Down the line the DB will 
> aggregate useful data in which the business will be interested in a 
> form of ad-hoc reporting. If you have a relational backend then its 
> very easy to use Crystal Reports (etc) to generate reports. Matter of 
> fact many people are even using Excel for that purpose.

I personally actually consider it an advantage if my database makes 
using Crystal Reports & Co. hard to impossible. That way, if a client 
asks for access to the DB, I can say sorry, but I'd be happy to provide 
other means for accessing that information, for example via 
webservices. :)

I'm saying this because I believe that an application-style database 
(one that is private to my set of applications) makes my life as 
application developer much easier than having to share an 
integration-style database with foreign apps. Data without business 
logic is kind of naked to me. For example, my application could present 
imperial units in the gui and use metrics in the DB; my business logic 
would take care of the conversion. Now if another app like Crystal 
Reports is bypassing my business logic to access the data directly, it 
would need to duplicate the metric-to-imperial conversion logic. 
Another point is that I'm more flexible in changing the schema of an 
application database than an integration database.

Fowler wrote a bit on this topic at: 
http://martinfowler.com/bliki/DatabaseStyles.html


Christian