1
I have an application where the user can create a task. The task in turn can be public or private. If it is public, other users may see it and favorite it. That is, many users may prefer the same task.
I thought of creating a third table, called Favorites. In this table I will have two fields, User_id (who is the little guy who preferred the task) and Task_id (which is the favorite task.
When I need to show this I filter via code. All right this or you suggest me something better?
3
Every relationship that is understood as "many for many" needs an intermediate table, like the one you explained.
In this case, as a person may prefer several tasks and a task can be favoured by several people, a table of association between the two entities is necessary to record this behavior.
I also recommend putting primary key as the combination of the 2 fields ( thus preventing a person from doing the same task more than once, assuming that this is not possible ) and a column with the date on which the event occurred, for record purposes
Browser other questions tagged modeling
You are not signed in. Login or sign up in order to post.
I think that’s right, put the two fields as the primary key, and think about creating a field in the task table to cache a times counter that was favorite, so you don’t need to query and count in the second table and you can sort by favorite of the most easily...
– Jader A. Wagner