On Sat, 12 Nov 2005 20:26:11 -0500, "John Siracusa"
<[EMAIL PROTECTED]> said:
> The Tangram docs have an interesting statement on the disadvantages of
> "filtered mapping"
> 
> > This mapping is very questionable according to relational orthodoxy. Even if
> > one decides to forgo these rules, using such a mapping takes away many of 
> > the
> > interesting features offered by modern RDBM systems. Because nearly all the
> > columns must allow NULL values, we cannot take advantage of features like
> > referential integrity constraints, domain constraints, indexes, etc.
> 
> I agree that it files in the face of "relational orthodoxy," but it
> certainly doesn't mean that referential integrity constraints and indexes
> are no longer applicable, or even any less effective.
> 
> I mention this because filtered mapping seems like the easiest technique
> to
> support with RDBO, so it'll probably be the first one I tackle.  Am I
> missing something here?

I agree both that it should be the first to implement, and that Tangram
overstates their case.
The "Filtered Mapping" does interfere with database-level
validation insofar as you can't declare "NOT NULL" on as
many columns. But it supports referential integrity quite
well *into* the mapped table.
It also can support pretty efficient SQL.

I put this table together to contrast the mechanisms (with
corrected names for the mechanisms, relative to my
initial email):

1. Table per class (aka "Vertical Mapping")
A single table with a primary key corresponding to the base class, and
a separate table for each subclass table sharing the same primary key.
The "base class" table has a discriminant column in addition to
its primary key value.

CON   query concrete class   requires a join to get all columns
PRO   query base class       easy, at least to get base columns
CON   create                 requires insert in multiple tables
PRO   integrity constraints  easy
PRO   ref to base class      easy

2. "Table per instantiable class" (aka "Horizontal Mapping")
Has a table for each instantiable subclass. Each such table has all
columns, including the primary key and all inherited columns.
There may not be anything
to ensure pkey uniqueness across these multiple tables.

PRO   query concrete class   easy select
CON   query base class       multiple selects
PRO   create                 easy
+-    integrity constraints  easy except for references to base class
CON   ref to base class      awkward (structured fkey or discriminant)

3. "Table per hierarchy" (aka "Filtered Mapping" aka "Union Mapping")
There is a single table that has a union of all columns from all
subclasses.
That table has a primary key and a discriminant column.

PRO   query concrete class   fairly easy, must filter rows and cols
PRO   query base class       easy
+-    creat                  have to know which columns
+-    integrity constraints  subclass columns must be "NULL"
PRO   ref to base class      easy (have to filter columns)

-mda


-------------------------------------------------------
SF.Net email is sponsored by:
Tame your development challenges with Apache's Geronimo App Server. Download
it for free - -and be entered to win a 42" plasma tv or your very own
Sony(tm)PSP.  Click here to play: http://sourceforge.net/geronimo.php
_______________________________________________
Rose-db-object mailing list
Rose-db-object@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/rose-db-object

Reply via email to