Re: Relational database & OO


frebe73@xxxxxxxxx wrote:
Worse, the application processing was often structured around the
preferred organization for the paradigm.

How could we do it different know, if we don't know anything about the
future paradigm?

Encapsulate the persistence mechanism behind a single subsystem
interface (an API in the Procedural Days). Design the subsystem
interface in terms of what the problem solution's needs for data are,
which will be independent of how the data is stored.

What is your definition of "store"? Store to a persistent medium, store
into a variable, store into another process, or?

Then let the
subsystem provide the mapping of that interface into the persistence
paradigm de jour.

If we use a RDBMS, the persistence part is already separated. The
application has no idea about if, when or how data is persisted.

Thus the application solution always requests, "Save this pile of data I
call X" and "Give me the pile of data I saved before as X." The
persistence access subsystem maps the X identity and the pile of data
into records in ISAM files, RDB tables, clay tablets, or whatever.

Is X always an identifier? Should you be allowed to use any predicate
logic in this interface ("give me the pile of data I saved before
having X=5 or Y=6")?

Fredrik Bertilsson

I think you might be misunderstanding. As you've already pointed out to
me, 'store' is a rather overloaded word, which can be applied at many
different conceptual levels. In this case, I think there are at least
three distinct conceptual levels:

1. What the data /is/

This would be the highest level of abstraction - information systems
deal with /information/, which is data interpreted in a particular
context. The application is typically dealing with things at this
level. IOW, the application is presenting the user with a time***
(information), as opposed to just a collection of numbers (data).

2. How the data is /represented/

We can represent time *** data in a number of different ways - the
relational model is a particularly good one, but other models were used
before it existed.

3. How is the data /saved to a persistent storage medium/

This is, as you pointed out, entirely encapsulated by an RDBMS, or by a
file system for example.

I think Lahman is talking about abstracting an interface (making an
API, if you will) between levels one and two. So your application would
have a generic way of saying "give me time *** X" or "give me all
time sheets for user Y". If flat files were being used at the time the
application was written, some implementation of the API would be
written which uses flat files. Perhaps one file is named after each
user, and stores a series of time sheets. When the RDBMS came along, it
would then be far easier to convert the legacy data, and very little
(no?) application code would need to be rewritten.

Note that I'm not trying to imply that the above API has to have
anything to do with objects. It could just as easily been procedural in
nature and achieved the same result.

-Matt McGill

.

Loading