title: Generic Resource Table Design Approach
body: <p>I'm sure this is a duplicate question but I haven't found a suitable answer yet, so I figured I'd ask about this (I would think) very common database design problem:</p>
  
  <p>I'm working on designing a SQL database which will have different record types that will contain images, so Tables A, and B, both of which house distinct record types, will have each of their rows linked to multiple image records. </p>
  
  <p>I am trying to decide whether to take the approach of creating 1 generic table to house all images (let's call it "Image") or whether to create two distinct tables ("AImage" and "BImage") to house the images of each record type separately. </p>
  
  <p>There will be a one to many relationship between A and its images and B and its images</p>
  
  <p>If I create the generic Image table, it would have as columns: Id, ParentType (A or B, in this case), ParentId. and ImagePath. This approach seems cleaner (especially since tables "AImage" and "BImage" would be identical to each other), but I encounter issues almost immediately (like when trying to establish Foreign Key constraints). I should note that there may be other record types in the database that will need Images with the same One to Many relationship as Tables A &amp; B. </p>
  
  <p>So what is the right approach here? </p>
  
  <p>Thanks. </p>