如何在SQL Server中建模互斥关系

Question

I have to add functionality to an existing application and I've run into a data situation that I'm not sure how to model. I am being restricted to the creation of new tables and code. If I need to alter the existing structure I think my client may reject the proposal.. although if its the only way to get it right this is what I will have to do.

I have an Item table that can me link to any number of tables, and these tables may increase over time. The Item can only me linked to one other table, but the record in the other table may have many items linked to it.

Examples of the tables/entities being linked to are Person , Vehicle , Building , Office . These are all separate tables.

Example of Items are Pen , Stapler , Cushion , Tyre , A4 Paper , Plastic Bag , Poster , Decoration"

For instance a Poster may be allocated to a Person or Office or Building . In the future if they add a Conference Room table it may also be added to that.

My intital thoughts are:

Item
{
  ID,
  Name
}

LinkedItem
{
  ItemID,
  LinkedToTableName,
  LinkedToID
}

The LinkedToTableName field will then allow me to identify the correct table to link to in my code.

I'm not overly happy with this solution, but I can't quite think of anything else. Please help! :)

Thanks!

Answer 1

It is not a good practice to store table names as column values. This is a bad hack.

There are two standard ways of doing what you are trying to do. The first is called single-table inheritance . This is easily understood by ORM tools but trades off some normalization. The idea is, that all of these entities - Person , Vehicle , whatever - are stored in the same table, often with several unused columns per entry, along with a discriminator field that identifies what type the entity is.

The discriminator field is usually an integer type, that is mapped to some enumeration in your code. It may also be a foreign key to some lookup table in your database, identifying which numbers correspond to which types ( not table names, just descriptions).

The other way to do this is multiple-table inheritance , which is better for your database but not as easy to map in code. You do this by having a base table which defines some common properties of all the objects - perhaps just an ID and a name - and all of your "specific" tables ( Person etc.) use the base ID as a unique foreign key (usually also the primary key).

In the first case, the exclusivity is implicit, since all entities are in one table. In the second case, the relationship is between the Item and the base entity ID, which also guarantees uniqueness.

Note that with multiple-table inheritance, you have a different problem - you can't guarantee that a base ID is used by exactly one inheritance table. It could be used by several, or not used at all. That is why multiple-table inheritance schemes usually also have a discriminator column, to identify which table is "expected." Again, this discriminator doesn't hold a table name, it holds a lookup value which the consumer may (or may not) use to determine which other table to join to.

Multiple-table inheritance is a closer match to your current schema, so I would recommend going with that unless you need to use this with Linq to SQL or a similar ORM.

See here for a good detailed tutorial: Implementing Table Inheritance in SQL Server .

Answer 2

Find something common to Person , Vehicle , Building , Office . For the lack of a better term I have used Entity . Then implement super-type/sub-type relationship between the Entity and its sub-types. Note that the EntityID is a PK and a FK in all sub-type tables. Now, you can link the Item table to the Entity (owner). In this model, one item can belong to only one Entity ; one Entity can have (own) many items .

Answer 3

your link table is ok.

the trouble you will have is that you will need to generate dynamic sql at runtime. parameterized sql does not typically allow the objects inthe FROM list to be parameters.

i fyou want to avoid this, you may be able to denormalize a little - say by creating a table to hold the id (assuming the ids are unique across the other tables) and the type_id representing which table is the source, and a generated description - eg the name value from the inital record.

you would trigger the creation of this denormalized list when the base info is modified, and you could use that for generalized queries - and then resort to your dynamic queries when needed at runtime.