Re: The IDS, the EDS and the DBMS

"Marshall Spight" <mspight_at_dnai.com> wrote in message news:wr3%c.387822$%_6.364464_at_attbi_s01...
> "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.

I don't say that about everybody. There are a handful of conributors in here that I regard as the voice of reason. You are one of them.

> 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! :-)

Well, there are a few "cabrones" in c.d.t., but you're not one of them.

> And by the way, the respect is mutual.

Thanks.
> > 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.")

OK, maybe not "the whole idea". But at least "the big idea". If one doesn't "get it" about data independence, then one doesn't "get it" about a DBMS, IMO (there I go again). One of the issues that deserves a whole lot more attention than it gets is this: "WHY use a DBMS, and WHEN to avoid using one".

>
> 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.
>

I mean the physical level, and a whole lot more.

> > > 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.

No! That phrase is new to me (or else I've forgotten). What does it mean?

I guess modularity is, to me, the containment of the ripple effect. A pond is not modular.

>
> 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.
>
It's what views were invented for.

In fact, I've seen Oracle databases where a given application has its own schema, and the schema consists largely of synonym definitions that make database objects in other schemas visible inside that schema. Functionally, it works like a "subschema".
The term "subschema" comes from CODASYL databases.

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

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

> > 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.

I just think that, in suddenly seeing the light about views, you are just beginning to see what was evident to me back in 1982, when I first started to get interested in relational databases. Views were an ESSENTIAL part of what I learned at the outset.

Without views, users of the data need to understand how to denormalize data. They shouldn't have to know that. Received on Tue Sep 07 2004 - 09:26:48 CEST