Re: Pre-relational, post-relational, 1968 CODASYL "Survey of Data Base Systems"
Date: Fri, 30 Apr 2004 01:01:47 GMT
Message-ID: <%zhkc.2274$Ut1.66398_at_bgtnsc05-news.ops.worldnet.att.net>
Ken North wrote:
>>one of the big arguments that i remember from the pre-relational dbms >>people in stl ... was the physical disk space requirements. The >>earlier databases had physical pointers ... which relational replaced >>with indexes. The indexes tended to double the physical space >>requirements (as well as increasing overhead) vis-a-vis the databases >>with direct physical pointers. The indexes, however, reduced the >>manual maint. involved in maintaining the physical pointers. The issue >>then was somewhat the disk space & processing overhead vis-a-vis the >>manual maint overhead.
>
>
> A CODASYL (network model), pre-relational database contains sets of records.
> Each set has an owner record and 1-n member records. The organization is similar
> in concept to the persistent representation of a doubly-linked list. There are
> pointers to the next and prior members of a set, but the CODASYL model also has
> a pointer to the owner of the set.
>
> The database designer or database administrator (DBA) define the set
> relationships in a schema that describes names, types, lengths, owner and member
> relationships. Using a network model database manager puts a premium on detailed
> design before you load data. There's no easy solution equivalent to SQL's ALTER
> TABLE.
>
> Making changes to the structure of a CODASYL database is non-trivial. If your
> database design uses the wrong length or type for a field (attribute), or omits
> one, you have to re-compile the schema and re-load the database to recreate the
> pointers.
>
>
That's my remembrance too, Ken.
Perhaps a more telling point is that, on any project which has more than one release, there is *always* a schema change (if nothing else than adding another field to some record). Converting from the release 1 schema to the release 2 schema often took a "3 day weekend" on customer premises, with the database inaccessible for use while this was going on.
Unload to disk (tape), install new schema, reload, sanity test.
You only got one shot at it, most of the time.
[Not that RDBMS's have solved all of
the problems. A trivial change like
adding a field to a record can be done
with alter table, but major overhauls
still cause the same fire drill.]
Another consideration was how to recover
after a pointer somehow got corrupted
and pointed to the wrong record or (most
often) never-never land. Not a pleasant
memory.
-- "It is impossible to make anything foolproof because fools are so ingenious" - A. BlochReceived on Fri Apr 30 2004 - 03:01:47 CEST