At 02:21 AM 7/21/00 +1000, Helen Borrie wrote:

>
>>In this application, a specialization hierarchy would have been
>>a great simplifier. Even though the underlying implementation
>>was much like a "super" table, the user visible model was
>>straightforward and intuitive.
>>

>Are you thinking of an extra meta-layer, then, somewhat analogous to a
>middle tier in an application?
>

Let me sketch an implementation. We may not want to do it, we may
think of a better way to do it. But here is a reference implementation.
(For the timing being I'm ignoring system table issues.)

First, SQL extensions:

create table <table-1> [EXTENDS <table-2>]...

No DML extensions are required. Examples:

create table event
(when timestamp, id integer, description clob);
create table hardware_event extends event
(hardware varchar, serial varchar);
create table software_event extends event
(software varchar, version varchar, host varchar);
create table database_error extends software_event
(filename varchar);

What happens under the covers is that the table "event" is extended
to contain fields object_type, hardware, serial software, version, host,
and filename. Tables hardware_event, software_event, and database_error
are virtual tables; record stored in any of these is actually stored in
"event" with the field "object_type" set to the virtual table name.

The semantic analysis phase of the compiler (cmp.c) does a symbolic
substitution for virtual tables:

select * from software_event

is mapped into:

select when, id, description, sofware, version, host
from event where (object_type = 'software_event' or
object_type = 'database_error')


insert into software_event (when, id, description, software)
values (...)

is mapped into

insert into event (object_type, when, id, description, software)
values ('software_event', ...)

Note that the boolean appended to the record selection expression
can be optimized very nicely by bitmap operations.

No change is necessary to the optimizer or runtime. It may be
desirable to add code to avoid cluttering indexes defined on
virtual tables with records that don't inherit from that virtual
table. No changes are required for index retrievals.

When all is said and done, the changes are essentially localized
to meta-data processing (met.e) and semantic analysis (cmp.c). The
system tables would retain their current semantic content, meaning
no changes to tools would be required. With the exception of the
EXTENDS clause to SQL DDL, no changes are required to DSQL.

>
>How would data objects be physically stored? Just as a general preview. I
>can see the logical model clearly enough and I can see that the logical
>layer doesn't actually need to know (or want to know) what happens down
>there when a script comes through with an instruction
> ClassTeaLady.CreateObject('Mrs Mop',.....)
>because that's all that's required, isn't it? Somewhere down there is a
>layer that knows how to create an object which is a Person which is an
>Employee which is an UnderpaidLifeSupportWorker which is...etc. right down
>to TeaLady.
>

Storing (narrow sense) objects in a database is a very losing proposition.
Storing object clusters (bunch of related objects) in a blob is a
different matter, but is essentially orthogonal to type hierachies.
If and when we get around to storage of serialized object cluster,
I'll drag out Object Cold Storage and its hyper-cute polar bear.

>>But there are people, employees, and managers that are both similar
>>and different. There are things you sell that come in boxes
>>that have unit prices, discount schedules, and shipping weight.
>>There are other things you sell, like licenses, that have unit
>>prices and discount schedule but are completely vaporous. You
>>can consider them differents objects, which complicates reporting,
>>or shoehorn them into the same object.
>

>
>>Skip Date. Read Patrick O'Brian instead. You'll learn about as much
>>about practical data management.
>
>Hmm, I've paid for Date so I WILL read him. Actually, I rather enjoy his
>style, it reminds me of my Dad.

Hey, that's much better than reading "Hannibal" and having it remind
you of your dad.



Jim Starkey