I have some tables, they are:
user
==============================
user_id | username | etc..
==============================
user_metadata
====================================
user_id | birthday | gender | etc..
====================================
game
========================
game_id | name | etc..
========================
I want to store users liking games, and since age attribute is important, I need to differ when did the like was made, it should be different entity if someone liked a game when he/she was in the age of 5 or was in the age of 8. So which of table structure would you recommend?
-
Store the age of the user when the likes made:
user_likes ========================================== user_id | game_id | user_age_when_liking ========================================== -
Store the timestamp
user_likes ========================================== user_id | game_id | liked_at (timestamp) ==========================================
So with the option number 2, if I need to get all users like with a certain age, I will calculate the year difference between the user birthdate and liked_at.
Other suggestion is very welcomed.
It mostly depends on the purpose of the use of the column. If you never need to do any time to time calculations (addition, subtraction etc) based on when the like occurred, than the age of the person is completely valid (basically you’re pre-evaluating birthDate-likeDate). However, if you have any intention of saying that someone liked a game 10 days ago, it will be much more work to reverse the pre-evaluated user-age back to a likeDate to allow another calucation. Keeping in mind that you most likely want to keep your database data extensible, using likedAt is preferred in my opinion.
I would also note that stackoverflow is not a site designed to answer theoretical questions that don’t have a specific code answer, this question should probably be on programmers.stackexchange.com.