I'm working on a forum system and need some advice on database design for a new feature: User Favourites. The system currently has four tables: Thread (posts), Comment, Category, and Topic.

The new Favourite feature should allow users to mark any of the four types of entities (Threads, Comments, Categories, Topics) as favourites. I'm uncertain about the best way to structure the Favourite table for this purpose.

Should I create a single Favourite table and use a type field along with an id field to reference the respective entity (Thread, Comment, etc.)? Or is it better to have multiple tables like Favourite_Thread, Favourite_Comment, etc., each corresponding to one type of entity?

I'm looking for insights into the pros and cons of each approach in terms of scalability, performance, and best practices in database design.


1 Answer 1


You're on the right track considering both options for your User Favourites database design. Here's a breakdown of the pros and cons of each approach, along with some best practices to guide your decision:

1. Single Favourite Table with Type Field:


  • Simplicity: Easier to implement and maintain, requiring only one table.
  • Flexibility: Supports adding new entity types as favourites easily by adding their IDs to the type field.
  • Query efficiency: Can perform JOINs with other tables based on the type and ID to retrieve favourite entities and associated information.


  • Redundant data: Stores the entity ID multiple times if a user favourites multiple entities of the same type. Data redundancy can sometimes foster a slower environment, no matter how you index.
  • Normalization concerns: Doesn't adhere to strict database normalization principles as the type field introduces redundancy.
  • Potential performance issues: Large-scale queries involving many favourite entities might be slightly slower due to joins.

2. Multiple Favourite Tables (Favourite_Thread, Favourite_Comment, etc.):


  • Normalized design: Each table holds data specific to its entity type, reducing redundancy and improving efficiency.
  • Scalability: Easier to accommodate adding new entity types by creating corresponding tables without changing the existing structure.
  • Potentially better performance: Queries might be faster for individual entity types as they have dedicated tables.


  • Complexity: Requires creating and maintaining multiple tables, potentially increasing code complexity.
  • Less flexibility: Adding new entity types as favourites requires creating new tables, which can be more overhead.
  • Potential data duplication: Some user information might be duplicated across all Favourite_X tables.

Best practices:

  • Consider the future growth of your forum system and the frequency of adding new entity types.
  • If future expansion is likely, the single Favourite table with a type field offers more flexibility.
  • However, if performance for large-scale queries is a major concern, separate Favourite_X tables might be beneficial.
  • Use consistent foreign key relationships between Favourite tables and the respective entity tables.
  • Consider employing caching mechanisms to optimize performance for frequent favourite access.

The best approach depends on your specific priorities and database needs. If simplicity and flexibility are paramount, the single Favourite table might be sufficient. However, if you prioritize optimal performance and data integrity for a complex system with diverse entity types, separate Favourite_X tables could be better.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.