Re: The IDS, the EDS and the DBMS

Laconic2 wrote:

> In this discussion, I'm trying to compare two very different reasons
for
> using a DBMS. I'm calling them the "integrated data store" (IDS) and
the
> "encapsulated data store" (EDS).

> The IDS is the classic DBMS of the 1970s or 1980s to me. It costs more
to
> get data into the database than to get data into a file, but you get
more
> value out of the data by using it to support more processes.

I think many interfaces to DBMSs (both from within languages and with consoles/"direct access") are awkward, but technologies like Hibernate and EJB3 QL and such (despite their problems and the entire object-relational "impedence mismatch") make it clear that there are many better options. I don't see dealing with files as easier in many languages.

> What do I mean by an EDS? Roughly, it's this: a database is built to
> provide persistence to some data in an object oriented environment.
> However, the data is seen as being somehow encapsulated within a class
of
> objects in the larger system.

So basically the difference between IDS and EDS is in the primacy of data over object (or vice versa), which is a judgment call on the part of the programmer?

The trouble that I see is that one ends up adding more and more "O-O" code which replicates capabilities already provided by the DBMS query facility. Some of that deals with the database per se (e.g. reading and writing data), and some of it deals with data internal to the application (e.g. finding "objects" that meet certain criteria).

> That is, there is a certain class of objects that "knows" how to
> interpret all the data in the database, knows how to operate
meaningfully on it,

The question is whether object wrappers around data and its operations and constraints is useful. Often it's just extra work - essentially you're writing methods (which often span multiple objects) that access data from the DBMS and then attempt to enforce constraints which are also specified in the DBMS.

> and knows how and when to write data to the database.

This is a trickier issue, but I've often wondered if it would be useful to treat the application as a distributed DBMS "node" in and of itself, and treat "persistence" in the same manner as distributing data updates across a distributed schema.

> Further publication of the description and prescription of the data
would be at best redundant,
> and at worst undermine the encapsulation of the class that knows how to
> use the database.

What value does encapsulating the data have? I've often heard that the objects can "buffer" changes in the data, but in 99% of cases I deal with, changes in the data necessitate changes in the application, not because you've encapsulated poorly, but because you're changing the data and its constraints, and those things need to be mirrored in the application.

> How to you spread the value of the data across the entire system? two
ways.
> First, you can define new classes that inherit from the class that
knows
> the database.

Are you referring specifically to "knowing" how and when to store data? Or also the meaning of the data?

> Second, you can use messaging to communicate between any class and the
> class that knows the database.
> That is, the OO system uses inheritance and messaging to enable
> integration.

I'm not sure inheritance buys you much here, other than code sharing which could just as easily be done via delegation. Messaging is (or not) implemented in O-O languages.

> In the IDS, the data itself enables integration. The data definitions,
> descriptions, and prescriptions (or maybe proscriptions) are included
in
> the database, and expressed as data (well, metadata). Thus, from a
data
> centric perspective, the database contains everything needed for the
> data's orderly use and orderly sharing.

Yes, I think that's a reasonable summary, although I'm not sure what place the word "integration" has in the above.

> It seems to me that many discussions in this forum have degenerated
into
> tirades because some of us have the IDS so deep under our skins that
the
> EDS strikes us as chaos, and the result of ignorance.
> Others have the EDS so deep under our skins that the mere concept of the
IDS
> seems at best quaint, and at worst counterproductive.

True enough. Since the relational model is so poorly taught and frequently misunderstood, and since O-O is trendy, I think igorance is a common root cause. That the EDS is chaos is evidenced by the technical environment around the time the relational model was invented; it was to overcome the chaos that Codd created relational.

Not that apps can't save data for its own purposes; but the purpose has to be understood as such. Saving data in a non-relational way, when it's meant to be shared (and when code sharing isn't properly managed), is asking for trouble.

> I'll admit that my own background leads me more towards the IDS than
the
> EDS.
I'm a convert; I learned COBOL and then SQL, later embraced O-O, and have just recently begun to identify the cause of my suffering as being the absence of good relational implementations, and object fever.

> But my purpose in this discussion is to move the IDS and the EDS from
the
> realm of unconscious reaction to the realm of conscious thought. That
> way, the discussion between "IDS types" and "EDS types" can be rational
and
> analytic, instead of visceral and parochial.

A noble goal indeed.

• erk