Re: VIEWS compared to Nodes as Windows into data
Date: Tue, 27 Apr 2004 13:37:36 -0500
"Laconic2" <laconic2_at_comcast.net> wrote in message
> > Yes and what just struck me with what you said is that with an RDBMS it
> > 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
> need to know whether the data is compressed or not.
> And, in particular, a query is independent of any columns it never
> Those columns can be altered, or dropped or new columns added and the
> still works. It's also independent of any tables not mentioned. New
> can be added, or existing tables can be altered or dropped, and the
> will still work.
> That's a considerable amount of data independence.
> 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
> 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
> 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
> 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.
Political correctness is overrated -- just stay away from "Man#" as a field name ;-)
> That reduces communication rather than enhancing it. Double plus
Received on Tue Apr 27 2004 - 20:37:36 CEST