At 09:11 PM 7/19/00 +1000, Helen Borrie wrote:

These are excellent question, particularly at this point. Let me
take a pass at them.

>
>I'd like to know what benefit I'd get out of table inheritance, never mind
>whether it be static, dynamic, single-i or multiple-i or Unknown-i.
>

The test of the value of any feature is the degree to which it
simplifies application programming. Adherence to established
sectarian doctrine sends a nice message, but when the rubber
hits the road, the only things that count are a) cost to develop
and maintain an application, and b) actual performance.

The application that got me started was a company that made network
management software. Much of what they did revolved around network
"events". There were many type of events: hardware events, software
events, human created events: A full, complex type hierarchy.
All events shared a number of fields. Hardware events had additional
fields, routers more, etc. Some parts of the application dealt
with all events, others hardware events, and so on. The database
design choices were not pleasant. Either an event could be
spread across a bunch of tables and reassembled with a join, or
a stored single "super" event table containing the union of attributes
for all event and rules for which fields applied to which events.

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.

We're not used to thinking about database applications this way.
I suspect the concept generalizes well, particularly in large,
complex databases. The only way I know to find out is to code
it up and see if the sucker flies.

>I've seen a "base table" proposed. I can understand how an
>ancestor-descendant model might be a useful option for creating descendants
>for a "root" entity in a structure that (relationally) represents deep
>nestings of attribute sets (such as I have in the tree for the IBDH, for
>example) but I see this as a very specialised kind of structure. I have no
>need to create 50 sibling customer tables (nor even five).
>

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.

>
>So - please bear with me - I have ordered C J Date's big book to try and
>get a handle on what's so bad about my current utilisation of an RDBMS as
>an abstract layer of data stored at map-references, with lives governed by
>"immutable rules of nature" which objects morphose in their own defined
>ways. At present I can use whatever language I prefer to implement the
>polymorphism.
>

Skip Date. Read Patrick O'Brian instead. You'll learn about as much
about practical data management.

>It makes me nervous to observe (perhaps fallaciously) that a metalanguage
>"very like Java" is going to be needed in the cold layer to manipulate what
>I manipulate now with an extremely simple, monolithic language. Am I
>mistaken in thinking that all this is leading to making IB into the thing
>that JDBDatastore ought to have been?
>

The language you're dealing with is syntactically more complex than
Java. It also has significant inconsistencies across subsystems.

>I reiterate - this is not a reactionary plea to change nothing! I REALLY
>want to be able to implant things like "standard" triggers to harvest a
>generator for a PK, populate case-insensitive search columns, calculate
>summaries for archive tables, I REALLY want the database to promote an old
>ODS automatically, de-da-de-da. I'd just want to know whether I want what
>you want. I don't mind having my illusions shattered, just don't scalp me
>for asking the question.
>

A quibble: I don't want the database to promote an old ODS. I won't
both the old and the new versions to coexist until I can figure out
whether the new version really works or not. Then I want a version
straddling gbak to save the old version to a CD to put under my
pillow, far far away from the new release, and test the water very
gingerly.

Jim Starkey