At 01:30 PM 6/8/00 -0400, Greg Deatz wrote:

>Personally....
>
>
>Of course, views, just like SPs, hide the mechanics of the underlying

database

>which is nice, but getting rid of "select-procedures", in my mind, would be a
>terrible thing. Am I wrong? Aside from pure elegance, are there compelling
>reasons to leave select-procedures behind?
>

My view of the value of database management systems has always been
that they provide a formalism that allows the development of ever
increasing higher level tools. The original design of DSRI/OSRI
grew out of what I considered to be a failed API for VAX Datatrieve --
it worked, but placed on unreasonable burden on application developers.
DSRI/OSRI were designed to support two flavors of interface: Preprocessed
programs and 4GLs.

To layer a high level tool on a database, the tool needs access to
a consistent source of meta-data. The DSRI architecture specified
a core set of system tables, not unlike the ODBC meta-data calls, but
a good decade ahead. A high level database tool works by understanding
the basic underlying database structures to supply a semantic base in
which to interprete user supplied language. This requires regularity,
predicability, normalcy, and a dense cross feature matrix.

Call this "pure elegance" or just effective design. They mean the
same thing.

The current quality of the InterBase tool set is abysmal. IBConsole's
"set term" is a crime against computingdom. The human factors are
bad, the diagnostics obscure, each component has gaping holes in
its functionality. The runtime info calls are becoming increasing
baroque until the doc group just gave up trying to document them.
More and more of the product as fallen into the category of undocumented
features.

So, yes, "pure elegance" is important -- criticially important. Its
absense leads to mush, chaos, and anarchy (as opposed by Ann-archy,
something quite different).



Jim Starkey