Re: VIEWS compared to Nodes as Windows into data

"Laconic2" <laconic2_at_comcast.net> wrote in message news:NKydneXQxeGlORPd4p2dnA_at_comcast.com...
> <orthogonal>
>
> > Yes and what just struck me with what you said is that with an RDBMS it
is
> > actually possible for a user to write a report using the query language
> > against something that is NOT just a logical view of the data -- YIKES!
>
> It depends. Most people would say that the tables themselves represent a
> logical view of the data.
>
> In most senses of the word "logical", that's true. The user doesn't need
> to know what disk the rows are on, or even whether they are all on one
> disk. The user doesn't need to know whether the data blocks that contain
> the table rows also contain rows from other tables or not. The user
doesn't
> need to know whether the data is compressed or not.
>
> And, in particular, a query is independent of any columns it never
mentions.
> Those columns can be altered, or dropped or new columns added and the
query
> still works. It's also independent of any tables not mentioned. New
tables
> can be added, or existing tables can be altered or dropped, and the
query
> will still work.
>
> That's a considerable amount of data independence.

Yup.

>
> And, in some really good implementations, the user doesn't need to know
> whether or not rows were stored before or after
> CITY was changed from CHAR(15) to CHAR(30).

This one always sounds like COBOL and card-columns to me - how often is it really, really a limit on a value that it be restricted in number of columns, unless this is a for-computer-purposes "code field" of some sort? Ah well -- some folks like more restrictions rather than fewer and this certainly helps clamp down on those users insisting on putting entire values into their forms.

> Incidentally, by "users of the data", I probably mean something
different
> than you do by "end-user". I'm using the term "users of the data" to
> include application programs that access the data, and then do things to
> it, before presenting it to the user. All of the good documentation I've
> read cautions against using SQL as an ad-hoc query tool for the "End
user".
> You have to know too much to use it right. Something like "Business
> Objects" might be better. If there is a more standard term for what I
mean
> by "users of the data", then I'd like to know it.

I'm using the same def as you -- the end-users of the database are both application software developers and their users. But, with PICK, the end-users could easily be non-IT professionals since the language is really very easy to use.

> But I'm not going to adopt "standard terminology" just to be "politically
> correct".

Political correctness is overrated -- just stay away from "Man#" as a field name ;-)

> That reduces communication rather than enhancing it. Double plus
> ungood.
>
> </orthogonal>
Received on Tue Apr 27 2004 - 20:37:36 CEST