<p>I am working on an application that will be used as an extensible framework for other applications.</p>

<p>One of the fundamental classes is called Node, and Nodes have Content. The SQL tables look like this:</p>

<p>TABLE Node ( NodeId int, .... etc )</p>

<p>TABLE NodeContentRelationship ( NodeId int, ContentType string, ContentId int)</p>

<p>It will be up to the developers extending the application to create their own content types.</p>

<p>Clearly this is bad from a relationship-database point of view as it is not possible to add a foreign key relationship to NodeContentRelationship.ContentId, even though it <em>is</em> a foreign key column.</p>

<p>However, the solution is quite simple and powerful so I am reluctant to change it.</p>

<p>What do you think - am I in for a world of pain down the track?</p>

Beware the
Inner Platform Effect
.
If you're trying to build an 'extensible framework' which allows developers to store data of different 'content types' and relate them to each other in a generic fashion, you may find that others have already
solved
this
problem
.