Re: Mapping objects into rdb

Johan Nilsson wrote:

> {Some of this is off-topic for comp.lang.c++.moderated, but it
> could lead to useful discussion about "practical C++" and
> "design patterns" topics. Please redirect database- or platform-
> specific followups to the appropriate newsgroups. Thanks. -mod}
>
> Hi,
>
> I'm designing a system where the objects' data need to be persistently
> stored in a rdb (Oracle8). For compatibility reasons with existing
> systems, I cannot use an odb. I'm doing the development in C++ and likely
> COM/DCOM.
>
> The database will not be some kind of enterprise system, it will be more
> of a technical application with very few users at a given time directly
> connected to the it. Much of the work will take place in the context of
> a few services/daemons which will communicate with the rdb, clients might
> (indirectly) use COM/DCOM for this.
>
> Does anyone have any experience on this? Is there any applicable design
> patterns?
 

> I would like all access to the database to go via the objects in the
> system (except for generating reports etc) and have a few initial
> wonderings :
>
> * How do you design the connection between the objects and the database?
> * The users of the objects should not have to know that they are
> stored/mapped into a rdb. How do you decide when to update the rdb from
> within the object?
> * How would you use transactions?
> * How do you implement collections of objects, which represents rows in
> the
> database? Efficiently?
> .....
>
> If you have any experience in designing and implementing a similar
> system, please share it with me.

 I helped design a similar system. The problem domain was highway traffic data. The system was responsible for collecting, analyzing, aggregating, storing, and reporting upon this data. The architecture was "three-tiered" client/server: the three tiers were the GUI clients, the closely coupled collection of cooperating processes that we called the server, and Oracle.

The entire system was written in C++. One of the server processes (we called it the Data-Pool Supervisor) served as the interface between the object world and the relational world. The Data Pool Supervisor was the only part of the system that had any knowledge of the relational world: the rest of the system dealt only with objects. The Data Pool Supervisor was responsible for transforming objects into relational entities, and vice versa. I still that high-level design decision was a sound one, but I cringe when I think about how we actually implemented the Data Pool Supervisor.

We relied heavily on Rogue Wave's DBTools.h++, but DBTools just pushed the real problem back one step (the real problem being how to map our custom objects to our custom tables). What DBTools bought us was database independence and a way to deal with the elements of an rDB as a series of objects. We still had to do the grunt work of object-relational transformation ourselves...and we did it poorly and inefficiently.

For every object that contained data elements that had to be stored in the database, we created an accompanying mutator object whose responsibility it was to decompose the object into Rogue-Wave RWDB* objects (and then call Rogue-Wave methods to store those objects in the database (or, conversely, retrieve those objects from the database and reconstruct the object). It was ugly, bloated, and slow. Bottom line: I don't have a design pattern for this kind of work, but I am pretty confident regarding that a few patterns or strategies to *avoid*.

If I had to do it again, I'd investigate Rogue Wave's newly announced RW-Metro solution, which is an object-relational mapping tool (http://www.roguewave.com/products/metro/). Maybe you can glean a pattern from their product overviews and white papers. Which brings up a whole boxful of Pandoras (to quote our former New Mexico State Governor): namely, intellectual property rights as they relate to patterns.

Good luck.

      [ Send an empty e-mail to c++-help_at_netlab.cs.rpi.edu for info ]
      [ about comp.lang.c++.moderated. First time posters: do this! ]