| Subject | Re: [IB-Architect] Table Inheritance |
|---|---|
| Author | Jason Wharton |
| Post date | 2000-07-19T02:40:22Z |
I'm with Jim. Let's work with strict inheritance for polymorphism and see
where that gets us.
I wonder if it would be possible to make it so that a table is thought of
more as a class definition. Each time there is a subclass it defines a new
table description where the ancestor table types are all inherited. Then,
there will be separate and parallel "natural order" data pointers for the
table.
An index or key declared at a base level is inherited by all sub-classes. An
index on a sub-class only affects and includes records which are at least at
that class level.
That way, it would be possible to have a table PERSON and then have a table
CUSTOMER and VENDOR. If there was a PK on PERSON_ID then it would be used as
the PK for the CUSTOMER and VENDOR table as well. If a UNIQUE index was
placed on CUSTOMER name it would still allow for a person be entered as a
CUSTOMER and a VENDOR.
As far as how this would affect the architecture of the versioning engine
I'm not completely sure but records would get tagged with a class level
instead of a table. Sub-class records would have duplicate table data
pointer pages referring to them (since each class would be made to appear as
a separate table) or somehow these could be collapsed and interwoven into a
single linked list where each base class would also maintain pointer threads
for sub-class records as well. Hope this makes sense.
The base class would have a linked list to all nodes of all sub-classes. For
each sub-class there would be an additional linked list thread that would
indicate the sub-set of records for the sub-class. So, in my example, you
would have let's say 8 PERSON records 5 of which are CUSTOMER and 3 are
VENDOR.
The node in the data page would look like this:
Node Address (using ID's but this would be a DB_KEY of some sort)
Next person
Next customer
Next vendor
The table data page pointers may end up being structured as follows:
0: 1, 1, 2 > (Root Node)
1: 2, 3, 2 > (Customer Node)
2: 3, 3, 5 > (Vendor Node)
3: 4, 4, 5 > (Customer Node)
4: 5, 6, 5 > (Customer Node)
5: 6, 6, 8 > (Vendor Node)
6: 7, 7, 8 > (Customer Node)
7: 8, END, 8 > (Customer Node)
8: END, END, END > (Vendor Node)
I think I got this little sample right... What I wanted to illustrate is
that each sub-class is laced into the main class and thus treated as either
a super table (at the base class level) and as a specific table at the
sub-class level.
I consider this in a raw form and I would be willing to bet that there is
some sort of sneaky algorithm that could efficiently compress things if a
very large number of sub-classes were anticipated to be used. The structure
above has a lot of repetition and in a larger class heirarchy there would be
even more repetition as each sub-class would bloat the data page pointers
one thread per sub-class.
How could some storage (i.e. I/O) optimizations be employed to trim this up?
For sure there would need to be provisions for abstract class levels such
that the physical implementation would only be certain specific classes. For
example, in this database we may only want records of type CUSTOMER and
VENDOR and none which are simply PERSON. Abstract class levels would provide
some flexibility for the code inheritance and not bottleneck the physical
storage side of things so much.
Perhaps I should try and whip up some glyphs to illustrate. If only there
was a whiteboard in front of us all...
Gotta get back to work... things to do before I go home tonight.
Regards,
Jason Wharton
CPS - Mesa AZ
http://www.ibobjects.com
where that gets us.
I wonder if it would be possible to make it so that a table is thought of
more as a class definition. Each time there is a subclass it defines a new
table description where the ancestor table types are all inherited. Then,
there will be separate and parallel "natural order" data pointers for the
table.
An index or key declared at a base level is inherited by all sub-classes. An
index on a sub-class only affects and includes records which are at least at
that class level.
That way, it would be possible to have a table PERSON and then have a table
CUSTOMER and VENDOR. If there was a PK on PERSON_ID then it would be used as
the PK for the CUSTOMER and VENDOR table as well. If a UNIQUE index was
placed on CUSTOMER name it would still allow for a person be entered as a
CUSTOMER and a VENDOR.
As far as how this would affect the architecture of the versioning engine
I'm not completely sure but records would get tagged with a class level
instead of a table. Sub-class records would have duplicate table data
pointer pages referring to them (since each class would be made to appear as
a separate table) or somehow these could be collapsed and interwoven into a
single linked list where each base class would also maintain pointer threads
for sub-class records as well. Hope this makes sense.
The base class would have a linked list to all nodes of all sub-classes. For
each sub-class there would be an additional linked list thread that would
indicate the sub-set of records for the sub-class. So, in my example, you
would have let's say 8 PERSON records 5 of which are CUSTOMER and 3 are
VENDOR.
The node in the data page would look like this:
Node Address (using ID's but this would be a DB_KEY of some sort)
Next person
Next customer
Next vendor
The table data page pointers may end up being structured as follows:
0: 1, 1, 2 > (Root Node)
1: 2, 3, 2 > (Customer Node)
2: 3, 3, 5 > (Vendor Node)
3: 4, 4, 5 > (Customer Node)
4: 5, 6, 5 > (Customer Node)
5: 6, 6, 8 > (Vendor Node)
6: 7, 7, 8 > (Customer Node)
7: 8, END, 8 > (Customer Node)
8: END, END, END > (Vendor Node)
I think I got this little sample right... What I wanted to illustrate is
that each sub-class is laced into the main class and thus treated as either
a super table (at the base class level) and as a specific table at the
sub-class level.
I consider this in a raw form and I would be willing to bet that there is
some sort of sneaky algorithm that could efficiently compress things if a
very large number of sub-classes were anticipated to be used. The structure
above has a lot of repetition and in a larger class heirarchy there would be
even more repetition as each sub-class would bloat the data page pointers
one thread per sub-class.
How could some storage (i.e. I/O) optimizations be employed to trim this up?
For sure there would need to be provisions for abstract class levels such
that the physical implementation would only be certain specific classes. For
example, in this database we may only want records of type CUSTOMER and
VENDOR and none which are simply PERSON. Abstract class levels would provide
some flexibility for the code inheritance and not bottleneck the physical
storage side of things so much.
Perhaps I should try and whip up some glyphs to illustrate. If only there
was a whiteboard in front of us all...
Gotta get back to work... things to do before I go home tonight.
Regards,
Jason Wharton
CPS - Mesa AZ
http://www.ibobjects.com
----- Original Message -----
From: "Geoff McInnes" <gmcinnes@...>
To: <IB-Architect@egroups.com>
Sent: Tuesday, July 18, 2000 7:09 PM
Subject: Re: [IB-Architect] Table Inheritance
> I assume then that the inheritance v interface
> discussion being moot, no one wants to dredge
> up CORBA v COM/DCOM? Or any of its variants or miscreants?
>
>
>
> ------------------------------------------------------------------------
> Learn Wireless Development Now!
> http://click.egroups.com/1/6356/6/_/830676/_/963972423/
> ------------------------------------------------------------------------
>
> To unsubscribe from this group, send an email to:
> IB-Architect-unsubscribe@onelist.com
>
>
>