Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    text
    copied!<p>Yes, this is possible. What you're asking for is "<a href="http://msdn.microsoft.com/en-us/library/bb738443.aspx" rel="nofollow noreferrer">table per hierarchy</a>" inheritance. Your table needs to contain any "discriminator column" which identifies the type of each row.</p> <p>However, no record for one person can have more than one concrete type when materialized (read from the DB), because an object can only have one type. <a href="http://blogs.teamb.com/craigstuntz/2008/07/17/37825/" rel="nofollow noreferrer">I've written about this issue before</a>:</p> <blockquote> <p>One of the mental barriers that you have to get over when designing a good object relational mapping is the tendency to think primarily in object oriented terms, or relational terms, whichever suits your personality. A good object relational mapping, though, incorporates both a good object model and a good relational model. For example, let’s say you have a database with a table for People, and related tables for Employees and Customers. A single person might have a record in all three tables. Now, from a strictly relational point of view, you could construct a database VIEW for employees and another one for customers, both of which incorporate information from the People table. When using a one VIEW or the other, you can temporarily think of an individual person as "just" an Employee or "just" a Customer, even though you know that they are both. So someone coming from this worldview might be tempted to do an OO mapping where Employee and Customer are both (direct) subclasses of Person. But this doesn’t work with the data we have; since a single person has both employee and customer records (and since no Person instance can be of the concrete subtype Employee and Customer simultaneously), the OO relationship between Person and Employee needs to be composition rather than inheritance, and similarly for Person and Customer.</p> </blockquote> <p>If "Bob" is a <code>Participant</code> who is both an Artist and an Author, then he cannot be of type, say, <code>Artist</code> and <code>Author</code> at the same time, unless one is a supertype of the other. Either Artist and Author should have a subtype relationship with the other or you should use aggregation rather than inheritance to relate <code>Participant</code> with <code>Artist</code> and <code>Author</code>. An instance of an object can have only one concrete type; this does not change because you store it to the DB.</p>
 

Querying!

 
Guidance

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload