How to split database models with SoC (separation of concerns) in mind?

Usually, a model should address a specific range of functions. For instance, the userModel addresses only things specific to a user. Nevertheless, when translated into code, does that mean that in the userModel, only queries to the users table is allowed?Allow me to illustrate this by an exemple. We have 3 tables like so:``` -- users id, email, password-- groups id, name-- users_groups_ownership user_id, group_id ```A user can belong to one or more groups, so for each group a user belongs to, there is an entry in the users_groups_ownership table.Whenever we want to get all the groups that a user belongs to, that's a job for userModel because we'll use a join from userModel.Now, if we need to add the user to a group, it would be an insert on the users_groups_ownership table, so should this be a dedicated model? Or inserting this table should be considered part of the userModel?I often find myself stuck in this kind of situation, not being sure if the structure is good or not. And I couldn't find any clear ressource on the matter.

Submitted November 19, 2019 at 06:43PM by Buzut