0

I am planning to have likes plugin in my website where: I have 18000+ of contents to display and 380+ users (more in future).

I thought to have the database table for the same as:

 ___________________
| User_Id | Post_Id |
|___________________|
|   15    |   288   |
|   185   |  14358  |
|   185   |   3855  |
|_________|_________|

If I store the values in the database, the database will have huge content and huge traffic and will need large storage too. (6840K values only for now then imagine the stage of values after 2 years.)

Any other best alternatives?

Akshay
  • 15
  • 5
  • 2
    This actually seems like the tidiest solution already if you need to know which user's liked which posts (otherwise you could use an aggregate *number of likes per post*). If by *large storage* you mean space taken on the disk - I'm betting it'll be far smaller than that taken by the *posts* data. If you're worried about the number of records - well, they're really simple records, just make a compound primary key on `User_Id` and `Post_Id` and it should be fine. – CD001 Jul 16 '18 at 10:46
  • The real "data" will be less, since not every user on your platform will like every post. – brombeer Jul 16 '18 at 10:48
  • @CD001 How to make a compound primary key on `User_Id` and `Post_Id`? – Akshay Jul 16 '18 at 10:51
  • Like [this](https://stackoverflow.com/questions/5835978/how-to-properly-create-composite-primary-keys-mysql) ;) – CD001 Jul 16 '18 at 10:53
  • storage is cheap. How much data are you anticipating, exactly? – ADyson Jul 16 '18 at 11:56

0 Answers0