From: Austin Ziegler <austin@...>
Date: 2002-12-18T21:55:50+09:00
Subject: Re: Data Modeling/Object Modeling (was Re: [OT] RE: help -- persuade my boss to adopt ruby)

On Wed, 18 Dec 2002 19:08:48 +0900, Gavin Sinclair wrote:
> Relevant to this thread, but not in reply to anything in 
particular:
> 
> Since relational DBs have advantages over OODBs in your opinion,
> Austin, what kind of strategy do you have for accessing them from
> an OO application?

It depends on the application itself. I have written code which
marshals and un-marshals through an abstract layer; I have written
code that has a specific "save" and "load" methods; and I have
written code that sprinkles SQL all through the program.

> I ask because, although I also very much like relational DBs,
> there is obviously a bridge to be crossed between the DB and the
> app. I've never seen this problem solved once and for all. In my
> experience:

I don't think it will be solved once and for all. I admit that there
is a fundamental disconnect between object models and data models
precisely because an object model is modeling the objects for use in
a *particular* program. To use a person-address example, while the
organization may need to keep track of the current and the last
three previous addresses (for some reason), the program you're
writing only cares about the current address. In this case, you may
wish to "embed" the address information in the person object -- but
it won't be stored that way. If, of course, you may be *updating*
the address, then you want to keep the address as a separate object
in any case.

> - one company wrote a layer for internal use that abstracted
>   queries and updates quite nicely - but I never hear of these
>   used wisely

> - I dislike having SQL code or even relational logic sprayed
>   throughout my code, yet writing a DB-access class for each data
>   class is cumbersome, uninteresting, error-prone, um .... ?

> The DB stuff in my current project is very nicely abstracted
> because the application affords it (i.e. it's not mundane "update
> customer" kind of stuff, but more abstract), but I don't like
> beginning new projects and coming up with DB access strategies all
> over again.

> Any thoughts?

Unfortunately, I can't offer any general advice. In general, I try
to treat each table as a class and each row as an object of that
class for marshal/unmarshal purposes, but then I may have objects
which I interoperate with as a container (HAS-A relationships) when
I need to combine this information in novel ways.

-austin
-- Austin Ziegler, austin@halostatue.ca on 2002.12.18 at 07.41.01