Re: Object-oriented Databases

Howdy Christian (et al.),

On 27/07/2005, at 7:04 AM, Christian Pekeler wrote:

>> 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.

These are very good points.

I also believe data is naked without its accompanying logic.

Unfortunately, I don't think we have reached this point yet.  A lot  
of enterprise developers don't think of the object model (realised in  
a framework or library) as being the foundation of all applications.   
Please don't misunderstand me, I'm all for their being one Customer  
class and one Product class and one ... and those being reused  
throughout a companies applications.  The problems I believe,  
however, are two-fold:

1.  It is unclear (to me at least) as to how much reuse you can  
really get from business objects across different applications (in  
the same organisation).  Do different apps really need the same logic  
and data etc.

2.  It is unclear (to me at least) how we can handle (in an OO  
fashion) efficiently fetching and process thousands or hundreds of  
thousands of objects, e.g. to create a report.

I'm thinking, perhaps, we need something like "Views" in an object- 
oriented system, that allow different applications to utilise  
different parts of the data and logic within a class without paying  
the full overhead of full object construction and use.  I'm not sure  
if it is possible, but imagine if you could fetch hundreds of  
thousands of your objects but only get a "virtual" representation of  
that object containing the metric data and the "get" method to  
convert it.

This way a reporting system could use the framework logic and  
database data, but at the domain model level of abstraction, and more  
efficiently.  Of course, there are many problems with the "solution"  
I propose.  Another possible solution could be running the  
application "in the database" so that there is never a penalty for  
constructing objects, they are always there ready to process messages.

Ok, just thinking out loud, probably a good bit of research could be  
done in this area.

Cheers,
Ashley.


--
Ashley Aitken
Perth, Western Australia
mrhatken at mac dot com
Skype Name: MrHatken (GMT + 8 Hours!)