Re: Is a Query langauge really necessary in an OODB?

In article <38d7c88c.38772291_at_News.CIS.DFN.DE>, spamfilter_at_rosinowski.de wrote:
> >> One of the nicer benefits of a query language is that 3rd party
 tools
> >> can be used.
 

> >I know (from other posts/threads) you don't have much use for OO, but
> >an overriding principle of good OO design is: Object shall implement
> >their own behavior.
>
> that doesn't address the problem. querying oodbms's objects and
> efficiently combining (aggregating, joining etc.) the results is
> certainly the oodbms' job. ...so you need a querylanguage right there.

Depends, if the OODB allows you to write server code to retrieve objects (and collections) directly from the store you can use the implementation language's collection classes (including associative containers) to build indexes that allow for rapid search and retrieval as well as more complex operations that are the OO equivalent of aggregating, joining, etc. This negates the need for a query langauge at that point (at least locally.. client/server & distributed apps bring transmission problems into play). Transmission problems can be solved through the use of dynamic agents (ie an active object (or network of objects) which encapsulates the data and code necessary for a particular operation). Thus it is theoretically possible to completely eliminate the query language requirement, but the question becomes: is it beneficial to?

>
> to be honest: why not joining the best of both relational and
> objectoriented worlds? navigation can be fast but declarative
> languages allow easier accesspaths. so one needs joining etc. what's
> the problem with this approach in general?
>

From my point of view, the problem is (in general) that I end up needing multiple models of the data. As a specific (warning: platform, tool, and library specific) example: I've often used VC++ on Win32 with the MS Access RDBMS. This particular configuration requires the development and maintenance of three separate data models; one for the GUI (dialogs/forms using MFC's DDV/DDX), one for business logic (C++), and one for the back end (fields/tables/etc.). The GUI/business model schism is a product of the development environment and can be eliminated using a better (more OO) framework, but the front/back end schism is fundamental.

In large projects, the problem would/could be lessened by project team organization (layering/compartmentalization). However, I typically work with _small_ businesses that have highly individualistic needs and the general rule of thumb is one project - one programmer/developer. In this environment multiple model requirements have a severe impact on cost. My ideal would be one model, one language, per project, with component reuse from project to project.

For all I know at present, there may be such a solution out there and I have yet to encounter it.

--
Brian L. Price
Have compiler will travel.


Sent via Deja.com http://www.deja.com/
Before you buy.