🚀 go-pugleaf

In article <> ark@sally.UUCP (Arthur M. Keller) writes:
>Network databases may explicitly
>support such connects but require the user to explicitly navigate
>through the database in a procedural manner.  The relational database
>approach allows for non-procedural navigation of substantially the
>same record types (but calls them "relations" instead.
>
>But in network databases, all
>retrievals involve writing programs, while this need not be the case
>in a relational DBMS.  Ad hoc queries are often allowed in relational
>DBMSs, but rarely allowed in network or hierarchical DBMSs.  In time,
>commercial relational DBMSs will become more efficient, in parallel
>with research technology advancing beyond.
>

The contention that all retrievals in a network database involve
writing programs is simply not true.  A good example being the QRS
subsystem of the MDBS III network DBMS.  This system will allow
you to generate output reports by specifying data items to be
retrieved, conditions to be met (e.g., all records from New Mexico),
and the sets to be traversed (in the proper order).  This type of
non-procedural query facility is available on many other network DBMSs
as well.

I've heard arguments to the effect that such a query system is difficult
to use as the user must know actual record/field names and specify
the proper search path.  This is true, but is not much more difficult
than specifying similar queries in Kman (where actual table/field
names must be used and proper selection of a search path via redundant
data fields is tricky).  I've used both systems (and Dbase III) 
extensively for teaching and personal use and I've found little advantage
of relational query languages over network query languages.


 
FROM:    Stephen D. Burd
USNAIL:  Anderson Schools of Management
         University of New Mexico
         Albuquerque, NM  87131

AT&T:    (505)-277-6418

UUCP:    {lanl,ucbvax!unmvax,gatech!unmvax,...}!unmc!burd