<p>Example</p>

<p>I have <code>Person</code>, <code>SpecialPerson</code>, and <code>User</code>. <code>Person</code> and <code>SpecialPerson</code> are just people - they don't have a user name or password on a site, but they are stored in a database for record keeping. User has all of the same data as <code>Person</code> and potentially <code>SpecialPerson</code>, along with a user name and password as they are registered with the site.</p>

<hr>

<p>How would you address this problem? Would you have a <code>Person</code> table which stores all data common to a person and use a key to look up their data in <code>SpecialPerson</code> (if they are a special person) and User (if they are a user) and vice-versa?</p>

Personally, I would store all of these different user classes in a single table.  You can then either have a field which stores a 'Type' value, or you can imply what type of person you're dealing with by what fields are filled in.  For example, if UserID is NULL, then this record isn't a User.
You could link out to other tables using a one to one-or-none type of join, but then in every query you'll be adding extra joins.
The first method is also supported by LINQ-to-SQL if you decide to go down that route (they call it 'Table Per Hierarchy' or 'TPH').