Which of these 2 database setups should I choose?

Question

I have 3 types of content: blogs, press releases, and reminders. All of them have a body and entered by fields. The blogs and press releases have a

Answer 1

I think you should think about the common fields. Do they really need to match?

If they need to match, it's easier to just put it in a single table.

Answer 2

I would sooner go without any sort of "type" field, instead making four tables: content, blogs, pressreleases and reminders. Content has the common fields enteredby, body, and title. For each of blogs, pressreleases and reminders, they have an id that is a primary key and also a foreign key to a content id. This makes a 1:1 "is-a" relationship. reminder can have the additional time field. To determine what type of entry a content row is, do a join select.

This may not be the best in terms of performance but it's better normalized.

Answer 3

The first one is the better construct, it allows for a content to have a specific set of required or common data in the content table and then specialized data in the child tables. This also allows you to add more types in the future with other requirements that still reuse the common elements in content but retain any unique data.

One other key question is if that data is required, for example do all reminders require an hour and do all blogs/press release require a title. If they are required then you ensure that those child tables will always be populated. If they are not then perhaps you should look at flattening the structure (yes Virginia you should sometimes denormalize).

So instead your content table simply becomes (nn = not null, n = nullable) id (nn) ,type id (nn), type (nn), body (nn), entered by (nn), title (n), hour (n). The main reason I usually find for doing this is that if the different data entities you are creating are so similar that over time it is possible they will merge. For example reminders at this time do not require a title, but in the future the might.

Answer 4

The first structure is a classic super type-subtype approach, and recommended. I would just suggest naming primary keys with full table-name-id like ContentID to avoid possible confusion.