Re: The IDS, the EDS and the DBMS

"Laconic2" <laconic2_at_comcast.net> wrote in message news:x6OdnasrEa9P-qHcRVn-oA_at_comcast.com...
>
> "Marshall Spight" <mspight_at_dnai.com> wrote in message
> news:2CO_c.112104$9d6.6707_at_attbi_s54...
>
> I need to preface these remarks with a general comment about your previous
> posts. There are literally dozens of times that I have not responded in a
> thread where you have posted a response before me. My reaction on reading
> what you wrote was that you said roughly what I was going to say, only you
> said it better.

Aw, shucks.

> So my view of you is that you generally have at least as much insight as I
> do. If I'm sometimes sharply critical of what follows,
> it's NOT a comment on what I think of your level of understanding.

Dude, you totally had me worried for a minute. After reading your disclaimers, I was prepared to be called a goat-lover or something. The actual disagreement was a huge anticlimax! :-)

I'm totally okay with people not agreeing with everything I say. I'd be in a bad way if I wasn't! As they say, "reasonable men can disagree." (This is assuming you are not a woman, although I believe the saying is intended to be fully general.)

And by the way, the respect is mutual.

> > While I've not heard it put in these terms, the idea of being able
> > to do data management and manipulation on data without having
> > to see all of the details is a great tool for modularity.
>
> It seems to be that the whole idea behind the DBMS, from the 1950s to the
> 1990s was that the data has more structure than the user or provider of the
> data is forced to see.

I'm not sure I'd agree that this is "the whole idea." Certainly it's in there, but I haven't seen much emphasis placed on it. Ahead of that, I'd put such things as normalization, declarative integrity constraints, and content-based addressing. (Pascal's "structure, integrity, manipulation.")

Unless what you're referring to is the physical data structures that implement the dbms's tables, in which case we're talking past each other, because I'm only speaking of the logical level.

> More than half of the databases built since 1990 were built for pursposes
> that are largely at cross purposes with the purpose envisioned by the
> earlier builders of the DBMS products. In other words, a lot of
> professionals learned how DBMS products work or, more, precisely how to work
> DBMS products. But they never learned, or disregarded, what DBMS products
> are for.

No disagreement here.

> >
> > Rough idea: views as a mechanism for modularity,
>
> I'm with Lauri on this: if views aren't for modularity, then what the heck
> ARE they for? Of course database people don't call it "modularity". They
> call it "data independence."

A lot of what I'm saying is just the fact that "database people don't call it 'modularity'."

But also there's the specific issue of attending to what modularity is. Do you know the phrase, "first there is a mountain; then there is no mountain, then there is a mountain again?" I'm right at the point where modularity is the mountain, and it's transitioning from not being there back to being there. So I'm thinking about modularity a lot.

The fact that all database tables are exposed to all clients in not modular. So what if a given application module could declare some subset (probably typically tiny) of the schema that it cared about, and what it expected them to look like, and the system could construct views accordingly? In one sense, this is just using the view mechanism that's been around all along, but it's using it in a new way, and for the explicit purpose of modularity. In some sense this is same-old-same-old, but in another sense, it's quite a new idea.

> I think of the terms "modularity", "encapsulation", and "data independence"
> as all addressing the same underlying issue.

I agree, but I still see them as three distinct (but related) terms.

> Here's the issue: If any part of a system could be intimately linked to any
> other part of a system, in ways that are not obvious in a schematic view of
> the "system", then that system is about as maintainable as a bowl of
> spaghetti.

Some linkage is essential; some is not. Modularity suffers when there are non-essential linkages.

> The folks who developed the three concepts above were all addressing that
> issue, even though their way of addressing it
> seems very different.

Sure.

> Again, in expressing what I think is obvious, I don't mean to slam you. I
> value your opinions.

I must have missed the part where you slammed me.

Marshall Received on Mon Sep 06 2004 - 22:06:52 CEST