Re: The IDS, the EDS and the DBMS

"Marshall Spight" <mspight_at_dnai.com> wrote in message news:inJ_c.245876$8_6.63461_at_attbi_s04...

> Okay, so at first the application guys/EDS people want persistence.
> Now it's circa-1960 for the DBMS crowd. Then they want shared
> access. Now it's 1970. Then they want concurrency and it's 1980.
> Now they want client-server and it's 1990. Then they decide they
> want the metadata after all. Then they discover they need ad-hoc
> queries, and declarative integrity, and by the way, structural
> inheritance is starting to look weak; can't we compose collections
> in some more general way?
>

> Thus Spight's Law is born. Those people need a DBMS; they just
> haven't realized it yet.

I'm not convinced. And I'm one of the "database types" more than one of the "application types".
I was an "application type" from about 1969 to about 1982. I think there is a need for an IDS.

But I don't think there is no need for the EDS. It's just born for a shorter lifespan and less mission creep than the IDS.

> When the OO people try to do data management without
> attending to the work done *in the field of data management*
> for the last 40 years, they're being, at best, NIH, and at worst,
> stump-ignorant.

I've run into almost no OO people in what I'm calling "production". In production, it's all about the data.
If a process screws up, then it's about the data it corrupted, or maybe about the results it never produced.
Fixing the the process is up to the developers, but getting back on the air is a matter of survival. So the OO people I've talked to were never very interested in data management. As far as they were concerned, "that's the clients problem, not mine."

Unfortunately, all this gives production people a very short sighted view, and data management is where the long view really pays off, if you can be patient enough and smart enough.

>
> Of course, the same can be said of relational folk who
> fail to attend to the lessons learned by application
> developers during the same period. As I said, we need not
> a mapping but a unification.
>

I'm probably guilty here. I read Booch and Rumbaugh and Coad, but I was much more interested in modeling than in programming at that point. So I'm really not a high powered OOP person at all. On the other hand, I think nothing of doing a whole new database build every week during the initial phases of a project, and let the evolving prototype reflect what I've learned in the way of analysis since last week's build. So the idea that doing a new CREATE TABLE is a cataclysm just strikes me a completely outside my experience. Received on Sun Sep 05 2004 - 22:53:00 CEST