Question

So imagine you have multiple tables in your database each with it’s own structure and each with a PRIMARY KEY of it’s own.

Now you want to have a Favorites table so that users can add items as favorites. Since there are multiple tables the first thing that comes in mind is to create one Favorites table per table:

Say you have a table called Posts with PRIMARY KEY (post_id) and you create a Post_Favorites with PRIMARY KEY (user_id, post_id)

This would probably be the simplest solution, but could it be possible to have one Favorites table joining across multiple tables?

I’ve though of the following as a possible solution:

Create a new table called Master with primary key (master_id). Add triggers on all tables in your database on insert, to generate a new master_id and write it along the row in your table. Also let’s consider that we also write in the Master table, where the master_id has been used (on which table)

Now you can have one Favorites table with PRIMARY KEY (user_id, master_id)

You can select the Favorites table and join with each individual table on the master_id and get the the favorites per table. But would it be possible to get all the favorites with one query (maybe not a query, but a stored procedure?)

Do you think that this is a stupid approach? Since you will perform one query per table what are you gaining by having a single table?

What are your thoughts on the matter?

Answer 1

I think you’re on the right track, but a table-based inheritance approach would be great here:

Create a table master_ids, with just one column: an int-identity primary key field called master_id.

On your other tables, (users as an example), change the user_id column from being an int-identity primary key to being just an int primary key. Next, make user_id a foreign key to master_ids.master_id.

This largely preserves data integrity. The only place you can trip up is if you have a master_id = 1, and with a user_id = 1 and a post_id = 1. For a given master_id, you should have only one entry across all tables. In this scenario you have no way of knowing whether master_id 1 refers to the user or to the post. A way to make sure this doesn’t happen is to add a second column to the master_ids table, a type_id column. Type_id 1 can refer to users, type_id 2 can refer to posts, etc.. Then you are pretty much good.

Code “gymnastics” may be a bit necessary for inserts. If you’re using a good ORM, it shouldn’t be a problem. If not, stored procs for inserts are the way to go. But you’re having your cake and eating it too.