Cortlandt Wilson <[log in to unmask]> wrote on HP3000-L:

>Alfredo,
>
>You wrote:
>> I wanted to repeat ALL of Jeff's wonderful essay because it captures the
>> essence of IMAGE databases.  IMAGE has built-in redundancy for safety
>> (just as airplanes have built-in redundancy for safety).  Pointers in
>IMAGE
>> are not necessary at all.  Pointers are there just for performance
>reasons,
>> to avoid serial scans.  You can dynamically add/delete/rebuild pointers
>at
>> any time (witness these Adager functions: PathAdd, PathDel, PathFix,
>>  MastPack, DetPack).
>
>I want to include that Codd & Dates conception of a relational database
>includes exactly the features you described (contrary to what Jeff wrote --
>if I understand him correctly).
>
>QUESTION:  Does Adager now allow one to rebuild pointers "at any time",
>including while the database is open by other users?

Pending DBQUIESCE from HP, Adager has to have exclusive access to the
database while modifying it.  There are some deeper issues having to do
with application-program design, though.  Take Adager's DetPack (which
reorganizes and relocates detail entries) from the perspective of programs
that build tables of detail entry NUMBERS.  After a "concurrent DetPack",
such programs will fail because the relevant detail entries may no longer
be where the program expected.  You can see that this can get quite
challenging from the application program's viewpoint (Adager's part is the
easy part; that's why I am in the systems programming industry and not in
the applications programming industry).


>IMAGE seems to have been designed so as to allow some relational style
>features to be added in the future.    For instance, I would like to have
>relational style "Primary Keys" (a.k.a. unique keys) in detail datasets.
>Having a relational type primary key also strongly implies support of
>concatenated keys.
>      While I don't know how hard it would be to add concatenated keys to
>IMAGE,  support of a unique key check would be fairly straight forward.
>To wit:
>    1.  Add a  unique key command to DBSCHEMA.
>    2.  Add a unique key flag to the root file.
>    3.  Add a new unique key error status code to DBPUT and DBUPDATE.
>    4.  Modify DBPUT and DBUPDATE (with CIUPDATE option) to check the
>length of the chain on the primary key path before adding or updating;  if
>the length is already > 0 then set the new error status and quit.
>
>If I understand the IMAGE internals correctly then the system overhead of
>this check would be negligible.   While concatenated keys might well
>involve more re-programming for HP's engineers the performance implications
>would again be negligible.

Excellent food for thought.  I have forwarded your comments to the SIEC
(SigIMAGE Executive Committee) for serious consideration as a useful
enhancement to IMAGE.


>When the DBQUIESE and multiple database UNDO (MXUNDO) commands come on line
>in the next year or so IMAGE will have two more key relational features to
>add to IMAGE/SQL.    The addition of a unique key option for detail
>datasets would bring IMAGE very close to Codd's minimal definition of a
>relational database.
>
>Not bad for a database released just 2 years after the first public
>publication of the earliest relational model!

I am sure Jon Bale and Fred White will be pleased by your kind words.


Cordially,

 _______________
|               |
|               |
|            r  |  Alfredo                     [log in to unmask]
|          e    |                           http://www.adager.com
|        g      |  F. Alfredo Rego               Tel 208 726-9100
|      a        |  Manager, R & D Labs           Fax 208 726-2822
|    d          |  Adager Corporation
|  A            |  Sun Valley, Idaho 83353-3000            U.S.A.
|               |
|_______________|


                                                                .