Question

I am good with ideas, but due to my limited programming experience I sometimes strain to come up with the most effective solution for a given concept.
Currently my mind is trying to fathom the most efficient way to reference a database table specific to a data type.

Concept

I am building an admin interface that allows a site owner to ‘build’ a content set based on selected content ‘containers’. The interface currently holds the various sql data types, such as int, varchar, text, etc. and allows the user to select the data type, label it, and then link them together into a group.

This group is then referenced as an instance of the data set and can be reused. For example, the containers ‘title’ and ‘body’ could used to build a simple page and each new instance of this group could be a new page.

Issue

The issue I am having is in referencing these containers in the most efficient manner possible. I can’t simply have a table with an instance id and a container id, because there is no way to know they type of container.
For example, the content-varchar table has an id field and then a value field in the format of varchar. The content-text table has an id field and then a value field in the format of text.

I thought about making one large table that held each possible type of data, but this would be a gross waste of space.
Currently I use a sub query to select the specific value from the relating table once I know the data type, but there has to be a better solution.

What are your ideas / suggestions?

Answer 1

Unless I’m missing something, this doesn’t sound terribly complicated. But it does sound like you’re putting a relational database inside a relational database. That’s usually the wrong way to go about things.

Still, if you insist, there’s a few observations to make here:

• A ContentSet defines one or more ContentItems.
• A ContentItem can be one of several well-defined primitive types, ContentTypes.

So, sounds like you’d have four tables:

• content_sets: ContentSets and their associated metadata, such as the user who created each one, the title of the sets, and so on.
• content_items: ContentItems, along with a foreign key to the ContentSet they belong to.
• content_types: A list of possible types that can be stored in each ContentItem. Your application will enforce whether the data being stored in each item is correct.
• content_groups: Instances of ContentSets, containing realized data and a foreign key to the ContentSet they are an instance of. Use a property bag/blob/text field to store the data itself.