Question

Say I have a table with 5000 records, and another table containing a list of 5 topics. Each topic is associated with 1000 records in the larger table – each comment has a ‘topic’ field which is a foreign key to the topics table.

For example, if the database stores all user’s comments on a website. There will be 1000 comments on topic A, 1000 on topic B etc…

If I want to obtain all the comments on a particular topic, I would have to write a query to obtain the correct 1000 rows out of a possible 5000.
What if instead I created 5 tables, each table storing comments about a particular topic only.

Assuming there would never be more than maybe 40 topics, is this a sensible approach to database design? I can’t see any obvious disadvantages, but it seems like it will produce faster query results.

Answer 1

Don’t go down that road.
It will not be faster, but it will soon become a maintenance nightmare because

• you’ll have to add a new table for every new topic
• you’ll have to do a lot of UNION ALL … style queries if you want comments for all topics,
  and you’ll have to modify every one of them if the list of topics changes (although this can be mitigated by clever usage of views)
• you’ll have to drop a table every time you want to get rid of a topic

Just put all comments in a single table, add a foreign key with an index, and you’ll be fine (5000 records is a very small amount of data, BTW – RDBMS systems usually handle millions of rows without any problems).