Re: The IDS, the EDS and the DBMS

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

Agreed.

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

It comes from Zen. The novice looks at the mountain and sees only a mountain. The initiate looks at the mountain, and understands that "seeing" is the projection of ideas onto the mind. He understands that in a very real sense, his experience is not the mountain, but simply his experience. There is not mountain.

The master looks at the mountain and sees a mountain.

The implication is that the master has now fully internalized the many details that the initiate has to wrestle with, and can simply *be* while still having full understanding. The beauty of the idea is that both the novice and the master have the same experience: a mountain, but it is with different levels of understanding.

I further understand this to describe one revolution on an upward spiral. Mountain, no mountain, mountain, no mountain, forever. We move to ever-higher levels of understanding.

A novice writes code. An initiate considers the definition of interfaces, carefully considers what algoritms to use, meticulously divides code into modules, etc. A master writes code.

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

Well, color me behind the times, then. :-) As I said, I'm an OO guy.

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

In these cases, if the application looks in the catalog, will it see all 200 tables in the system, or will it only see the 37 tables it uses itself? I've never heard of the latter situation, but maybe it's just my lack of experience.

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

Well, I'm not exactly suddenly seeing the light. I'm suddenly seeing them in a new light.

Let's talk about views some more. Clearly it's an area I have a lot to learn about.

Marshall Received on Tue Sep 07 2004 - 18:19:04 CEST