Re: The IDS, the EDS and the DBMS

"mAsterdam" <mAsterdam_at_vrijdag.org> wrote in message news:4138b7a3$0$78749$e4fe514c_at_news.xs4all.nl...
> 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). What I think I've seen is that people
who
> > build an IDS and people who build an EDS use the same tools and methods,
>
> Nice! Let's see if I understand.
>
> Tools - to some extend: a DBMS.
> Methods ... hmmm ... what do mean by methods?

Oops. I shouldn't have used the word "methods". What I meant was closer to "the same tools and techniques". Sorry about that.

> Encapsulation is a rigid way of doing information hiding.

> The IDS is rather indifferent to what method is used to build the
> applicaction. The unit of integrity is the database.

Yes. In other words, in my view, the application is one great big capsule. Evrything inside of it is encapsulated. And there is usually more than one application,
and they don't "talk" to each other, except by writing and reading the data in the database.

Therefore, data passed between applications and the database is the fullfillment of a contract
to supply data between applications. Any application that doesn't fulfill its contract is a rogue.
Rogues that read data do so at their own risk. Rogues that write data need to be brought into compliance.

But this is the IDS vision of what a database is for.

But the EDS vision is nearly the opposite. EDS designers "hide" the information in a database so that it will persist when the application is rebooted. But going into such a database to pull out information with SQL or any other tool is drilling into the capsule. It's hacking into information that was not written to be shared.

> The EDS's unit of integrity is the application.
> I could very well imagine a system, consisting of
> several EDS's, interconnected through well-defined
> store/forward mechanisms. It could behave to the outside
> world as one unit - establish a larger EDS.
>

Doesn't EDI intend to accomplish this goal?

> > Encapsulation is an important concept. Used appropriately, it can
contain
> > the collateral damage done when a very large system is revised and
extended.
> > I call this collateral damage "the ripple effect". In my structured
> > programming years, I might have used modularity to contain collateral
> > damage, but I think encapsulation clarifies and expands the concept
beyond
> > my own concept of modularity.
>
> How so?

Well, back when I was writing "structured programs", the basic tools for modularizing a big program were subprograms: procedures and functions. Procedures and functions have local variables (in a structured language like Pascal), but these local
variables do not persist between invocations of the subprogram. If a subprogram wants to behave more like an object, and "remember" things between calls, it has to hide that information in plain view, by stashing it in some kind of global or dynamic data structure.

That's persistent (so long as the program runs), but it's not encapsulated. Right?
>
> Let's give it a try.

Good start. Thanks for the questions. Received on Sat Sep 04 2004 - 14:37:48 CEST