SQL many-to-many

Question

I need to build a simple forum (message board) as a school project. But I came across one problem. In the img above there are 2 tables: post and category , which have many-to-many relationship. I made a bridge table, which stores the postKey and categoryKey . Is it a bad practice to create a composite primary key from those 2 keys, or I need something like postCategoryKey ? And what else should I improve?

Answer 1

On my opinion, there is no need for PostCategoryKey, due to it's only a relationship table and you won't accés it by postCategoryKey. I would create the PK using the 2 others FK (postKey and categoryKey).

Hope it helps!

Answer 2

It depends, if you plan later on to add some extra metadata to postCategoryKey in a separate table, then it makes sense.

In your case - I'd go with a composite primary key and get rid of postCategoryKey

Answer 3

You will have to make postKey and categoryKey not null and create a unique constraint on them anyway. That makes them a key for the table, no matter whether you call this the "primary key" or not.

So, there are three options:

1. Leave this as described with NOT NULL and the unique constraint.
2. Declare the two columns the table's primary key.
3. Create an additional column postCategoryKey and make this the primary key.

The decision doesn't really matter. Some companies have a database style convention. In that case it's easy; just follow the company rules. Some people want every table to have a single-column primary key. If so, add that PK column. Some people want bridge tables to have a composite primary key to imediately show what identifies a row. My personal preference is the latter, but any method is as good as the other actually. Just stay consistent in your database.