You can map inheritance to database tables in the following ways,

• Map the entire class hierarchy to a single table: All attributes of the classes are stored in one table. This is a good strategy for simple and/or shallow class hierarchies where there is little or no overlap between the types within the hierarchy.

• Map each concrete class to its own table: A table is created for each concrete class, each table including both the attributes implemented by the class and its inherited attributes. This is a good strategy when changing types and/or overlap between types is rare.

• Map each class to its own table: Create one table per class, with one column per business attributes and any necessary identification information (as well as other columns required for concurrency control and versioning). This is a good strategy when there is significant overlap between types or when changing types is common..

As said, none of these mapping strategies are ideal for all situations. Experts recommend to start with one table per hierarchy at first, then if needed refactor schema accordingly.

Do you know how to call this described pattern?

Catalog of Patterns of Enterprise Application Architecture calls this Inheritance Mappers.

I have been running into something similar, with a base table of Persons, a useful abstraction, and then other tables depending on whether they are Contractor, Client, etc.

For the table design, if the “sub table” (in your case, Book, Article) cannot exist without being Content, then I’d go with your design, and use the Content_ID as the key for Book and Article as well.

Since I use PHP, I have a class that handles Content, then a class that extends that to handle Books/Articles.

If you are using the database, I’d recommend a VIEW which SELECTS and JOINs the Content-Book tables, and another with does Content-Articles for ease of use.

If you know in advance the entire set of possible types of content you could use table-per-hierarchy and stick all of the books, articles etc. sub-classes of Content into one table,
If, on the other hand, you may (or already know you will) need new subclasses of Content later on I’d use table-per-subclass (like you are thinking about)

So, the question in my opinion is to ask: Is my set of Content subclasses complete or should it be easily extendable later?

Your model is solid because you have a strong idea about the different types of content you want to manage (books, articles, etc.). Having a table for each type of content defines the different attributes. You can probably predict over 90% of the types you’ll need for several years.

If you put them in one large table, you will have several columns that will be null. There are some databases that have improved the handling of sparse data and can save on space. From a data query perspective, you can include different types of content very easily.

I’ve seen several systems (mainly enterprise apps) where they provide greater flexibility for user-defined fields. Unlike your situation, they can’t predict all the entities. A flexible way to do this is with a Entity Attribute Value Model. The joining of extra tables and possibly transposing row data into columns, performance is sacrificed over user flexibility. Basically, do you want your app to be programmer/code driven or user/data driven?

You may want to consider how you’re going to handle searching. There are tools out there to make this easier. I’ve you’re going to build your own, you have to deal with multiple tables.

Maybe a NoSQL solution should be considered?