At 10:52 AM 20-07-00 -0400, you wrote:

>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.

I wouldn't argue with that at all on principle...

>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.

Sure: and somebody has to DO the thing first before those bottom-line
issues can start to be evaluated.

>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.

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

(Metadata layer converses with middle-meta-layer which exposes properties,
events and methods to the SQL parser? Analogous to database layer
converses with object layer which handles all database conversations for
the client application...)

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.

> >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.

On the other hand, the shoehorn model is very adaptable. In a normalized
structure, if I want to add new attributes to something, I just create a
new relation and hook it on with a key. (OK, you're right, that's
sectarian!) Won't inheritance force an inflexible structure? or a
proliferation of classes that has deep ramifications in the hierarchy and
across versions?

>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.

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

Are you considering unifying everything from the SQL parser-down in Java?

>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.

Forgive me, that was a slightly tongue-in-cheek push on a hot-button...

Thanks for the comments - i hope these layperson questions aren't a waste
of energy.

Kia ora!
Helen
http://www.interbase2000.org
___________________________________________________
"Ask not what your free, open-source database can do for you,
but what you can do for your free, open-source database."
(J.F.K.)