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
