Re: The IDS, the EDS and the DBMS

"mAsterdam" <mAsterdam_at_vrijdag.org> wrote in message news:413cddac$0$36860$e4fe514c_at_news.xs4all.nl...

> >>Persistence is sharing data between multiple subsequent
> >>instances of the same program.
> >>Concurrency control and shared access solve the
> >>problems of sharing data between multiple simultane
> >>instances of the same program.
> >>Metadata comes into play when data is shared between
> >>really different programs. *Really* different as in not
> >>sharing the same code.
> >
> > Agreed.
> >
> > I might want to rephrase "the same program" as "objects of the same
class".
> > But I'm not sure of this.
>
> I wasn't when trying to formulate this.
> In this case "objects of the same class" opens up a
> can of irrelevant watchameanbyzats, so I settled
> for "program".

Fair enough. In my own mind, I still think of "multiple successive instances of the same process", "multiple concurrent instances of the same process", and "multiple distinct processes". But this terminology is way out of date.

I think I walked into the watchameanbyzats somewhat deliberately, when I chose the word "encapsulated" for the EDS. The reason I choose "objects" for the "unit of interaction with the database" is that object oriented people are oriented towards... well... "objects".

And, very specifically, there was a conversation in here a few months ago in which an OO person challenged the necessity of having the database metadata describe the data by saying something along the lines of, "if we hide the metadata inside the object class, it doesn't need to be in the database." That may not be the exact wording used, but it's close.
>
> I'll abuse this to introduce one thing as if I had
> thought of it originally (well I did, honestly, but I
> forgot to write it down): shared access is (possibly)
> sharing from different locations.
>
> Somebody now may wrap this up into a nice article about
> levels of data sharing, prerequisites and implications :-)
>

I would like the nice article to at least reference the classic works on "semaphores", "race conditions", and "concurrency". No sense reinventing the wheel, unless it's really a new wheel.

> When you're not part of the solution, there is a lot
> of money to be made in postponing it.

Good one! Received on Tue Sep 07 2004 - 09:00:15 CEST