title: Azure Table Storage: Storing Relationships
body: <p>When storing a one to many relationship in Azure Table Storage (such as storing the ID of the owner of a record) do you store both the PartitionKey and RowKey as two separate fields? Or do you somehow concatenate those two fields into one field for the purpose of simpler storage?</p>
  
  <hr>
  
  <p><strong>EDIT - more clarity on what I'm asking</strong></p>
  
  <p>I know table storage is not relational. And I'm not looking for foreign key integrity or cascading deletes or anything like that. </p>
  
  <p>But even without being "relational" there is still a very common need to store a pointer to a record in another table. This has thousands of uses. My example of storing the user who created the record is just one example. Storing any sort of list or array is another example (such as a list of "Work Experience" records in a resume, or a list of contact addresses for a Person record.)</p>
  
  <p>Because the "primary key" of an Azure Table Storage table is two fields, I'm wondering if there is a common convention on how to store that information. What is the "Best Practice?"</p>
  
  <p>The options I see are:</p>
  
  <ul>
  <li>Concatenate PartitionKey and RowKey into one field and store that as the "Foreign Key" (I know there are no real foreign keys).</li>
  <li>Store both fields separately and use those as the foreign key.</li>
  <li>A third option I haven't thought of.</li>
  </ul>
  
  <p>Is there a "best practice" here? Is there a reason to choose one method over another?</p>