title: Grouping records with or without a foreign key constraint
body: <p>I have a table containing objects, something like this:</p>
  
  <pre><code>PK ObjectId
  FK ObjectTypeId
  Description
  etc
  </code></pre>
  
  <p>The objects need to be grouped.  I have been given a number of suggestions, all of which 'work' and some I like more than others.  None of them are perfect so I'm struggling to settle on any particular model.</p>
  
  <p><strong>1/ Add a self-referential foreign key</strong>. This is clean but not ideal because (a) there is no logical parent (it's a group, not a hierarchy) and (b) it is potentially a pain for LINQ-to-SQL to traverse a self-referential hierarchy - would need to check to see if the current object is a 'parent' or a 'child' object, etc.</p>
  
  <pre><code>PK ObjectId
  FK ParentObjectId
  </code></pre>
  
  <p><strong>2/ Add a parent table &amp; a foreign key</strong>. This adds constraints but the Group table doesn't contain any useful information - it exists only to provide a GroupId constraint &amp; identity.</p>
  
  <pre><code>Table Object
  PK ObjectId
  FK GroupId
  
  Table Group
  PK GroupId
  </code></pre>
  
  <p><strong>3/ Add a GroupId without a constraint or foreign key</strong>. No data integrity. The theory is that when a new object group is inserted, each object is given GroupId = the first assigned ObjectId.  Probably the simplest &amp; most practical solution.</p>
  
  <p>e.g. </p>
  
  <pre><code>ObjectId  GroupId
  ...
  15         10
  16         16
  17         16
  ...
  21         16
  22         22
  </code></pre>
  
  <p>My question is which of these is the best in theory and/or practice, and why.  Or, please tell me a better way to do this!  I personally like (2) because it is normalized, but am told that a table with just one field is bad design.  Thoughts and suggestions?</p>