Subject | Re: Table Inheritance |
---|---|
Author | Helen Borrie |
Post date | 2000-07-19T11:11:35Z |
All,
I'm not a database architect so I'm not presuming to say what's good or not
good about the proposals for table inheritance. What I'd really like to
know, though, is why I should be happy about the idea of IB being
transmogrified into an OO database, presumably making all foregoing
relational structures incompatible with IB-Next.
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.
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).
Note, I'm not presenting an argument AGAINST table inheritance: I'm
genuinely questioning why it's seen as a necessary forward step for IB,
sincerely wanting to know how the proposed semantic changes are going to
make it better.
I'm more accustomed to needing structures that are networks of dependency,
rather than hierarchies. I use intersection tables and joins to surface
the properties of my "data objects". I can create an object layer in
middleware that can completely encapsulate any interactions between these
objects that are not already hidden in the "cold", abstract, database layer
as triggers, procedures, constraints and control structures.
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.
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?
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.
Regards,
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.)
I'm not a database architect so I'm not presuming to say what's good or not
good about the proposals for table inheritance. What I'd really like to
know, though, is why I should be happy about the idea of IB being
transmogrified into an OO database, presumably making all foregoing
relational structures incompatible with IB-Next.
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.
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).
Note, I'm not presenting an argument AGAINST table inheritance: I'm
genuinely questioning why it's seen as a necessary forward step for IB,
sincerely wanting to know how the proposed semantic changes are going to
make it better.
I'm more accustomed to needing structures that are networks of dependency,
rather than hierarchies. I use intersection tables and joins to surface
the properties of my "data objects". I can create an object layer in
middleware that can completely encapsulate any interactions between these
objects that are not already hidden in the "cold", abstract, database layer
as triggers, procedures, constraints and control structures.
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.
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?
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.
Regards,
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.)