Re: many to many tables in the direct mapping

Cc:+= Michael Stonebraker <stonebraker@csail.mit.edu>

* Richard Cyganiak <richard@cyganiak.de> [2010-11-02 12:39+0000]
> Eric,
> 
> On 2 Nov 2010, at 08:56, Eric Prud'hommeaux wrote:
> > The monotonic addition of columns to the database results in
> > non-monotonic changes to the direct graph, breaking existing queries
> > and mapping rules.
> 
> I don't find this reason compelling.
> 
> Changes to the source database break queries and mapping rules. That
> is sort of obvious. It will not come as a surprise to users either
> -- changing your database messes up your SQL queries and views too.
> 
> Removing or renaming a column will break things no matter what. Same
> for adding or modifying primary or foreign keys. If adding a column
> to a many-to-many table breaks queries or mapping rules too, then so
> what? I don't see what's so special about that operation.
> 
> As a matter of principle, I think this WG should not inconvenience a
> large number of users (everyone who has many-to-many joins in their
> schema) in order to maintain some notion of theoretical purity
> (monotonicity).

It's not some theoretical goal that motivates me; "monotonic" just
happens to aptly describe the set of changes I can make to a
relational structure and not have to revisit every piece of code which
queries that structure.

I chatted with Mike Stonebraker about this and he had similar
reservations about having a different direct mapping for tables whose
attributes happen to be covered by exactly two primary keys. While his
concearns were more about complexity, he did offer the counter example
for the many-to-many detection scheme: A marriage table may well have
exactly two spouses in it, but it's not (in most places) a many-to-many
situation. I think that the many-to-many-ness must be opt-in, and not
in the direct/default mapping.


> > It will be harder for folks to write papers and innovate soundly
> > with a more complex model.
> 
> The interests of users should outweigh the interests of folks who
> write papers too.
> 
> Best,
> Richard
> 
> 
> 
> 
> >
> >¹ http://www.w3.org/2001/sw/rdb2rdf/directGraph/alt#id0xa4a2a060
> >² http://www.w3.org/2001/sw/rdb2rdf/directGraph/#rules
> >
> >For example, consider a PersonAddress table which connects a Person to
> >an Address:
> >
> >┌┤Person├────┐  ┌┤Address├───────┐  ┌┤PersonAddress├───┐
> >│ ID │ fname │ │ ID │ city      │  │ person │ address │
> >│  7 │ Bob   │ │ 18 │ Cambridge │  │      7 │      18 │
> >│  8 │ Sue   │ │ 19 │ Austin    │  │      7 │      19 │
> >└────┴───────┘ └────┴───────────┘  │      8 │      19 │
> >        └────────┴─────────┘
> >We can generate a direct graph for PersonAddress
> >@base <http://db.example/ContactDB/> .
> >
> ><PersonAddress/person.7_address.18#_>
> >   <PersonAddress#person> <Person/ID.7#_> ;
> >   <PersonAddress#address> <Address/ID.18#_> .
> ><PersonAddress/person.7_address.19#_>
> >   <PersonAddress#person> <Person/ID.7#_> ;
> >   <PersonAddress#address> <Address/ID.19#_> .
> ><PersonAddress/person.8_address.19#_>
> >   <PersonAddress#person> <Person/ID.8#_> ;
> >   <PersonAddress#address> <Address/ID.19#_> .
> >
> >OR, as I believe you propose, we can generate repeated properties:
> >
> ><Person/ID.7#_>
> >   <PersonAddress/person_address> <Address/ID.18#_> ;
> >   <PersonAddress/person_address> <Address/ID.19#_> .
> ><Person/ID.8#_>
> >   <PersonAddress/person_address> <Address/ID.19#_> .
> >
> >This one is attractively more terse, but, the addition of a column to
> >the database:
> >┌┤PersonAddress├───┬─────────┐
> >        │ person │ address │ primary │
> >        │      7 │      18 │ true    │
> >        │      7 │      19 │ false   │
> >        │      8 │      19 │ true    │
> >        └────────┴─────────┴─────────┘
> >
> >*retracts* those repeated properties and generates instead a direct
> >graph for PersonAddress with the three additional primary predicates:
> >
> ><PersonAddress/person.7_address.18#_>
> >   <PersonAddress#person> <Person/ID.7#_> ;
> >   <PersonAddress#address> <Address/ID.18#_> ;
> >   <PersonAddress#primary> "true"^^xsd:boolean .
> ># + 7_19 and 8_19
> >
> >These retractions break queries and change the interface graph even
> >though the addition of the column does not change the interpretaion
> >of any of the other columns in the database.
> >-- 
> >-ericP
> >
> 

-- 
-ericP

Received on Wednesday, 3 November 2010 20:44:04 UTC