1

I am having two tables pages(id,name) and posts(id,msg) In both pages and posts having id field which is auto incremented and starts from 1

I want to create like table when a user likes a post or page details should be stored in like table.

My question is should i use different like table for post and pages

  1) page_like(page_id,user_id);// (page_id,user_id) composite PK
   2) post_like(post_id,user_id);//(post_id,user_id) composite PK

or should i use

 like(element_id,element_type,liked_by) //(element_id,element_type,liked_by) composite PK

Which method should i use and why ? Is there better way to do this?

xrcwrn
  • 5,339
  • 17
  • 68
  • 129

2 Answers2

0

If you have two distinct keys that automatically increment individually for page and post, I would definitely use two separate tables. It wouldn't make sense for you two have a row that has a post and a page with two sets of distinct keys.

dckuehn
  • 2,427
  • 3
  • 27
  • 37
0

Out of the choices presented, you should definitely go with the first one. The alternative prevents you from declaring a FOREIGN KEY, and enforcing referential integrity in the application code is surprisingly difficult.

That being said, there is a third option: "inherit" both post and page from a common "super-table", then like the super-table directly. This is probably not justified for just two sub-types, but can be very useful if you anticipate your model will grow in the future. I have described the basic idea here.

Community
  • 1
  • 1
Branko Dimitrijevic
  • 50,809
  • 10
  • 93
  • 167