Without knowing the real requirements there is not much to help, they are always the ones who will define what is right or wrong. If there was only one way to do it then everything would be ready and no one would ever have to do it again. Even in an exercise he needs to define well what he wants.
Abstractly, within my knowledge, I see no reason why there should be a table of login, after all already have this information in the users table.
The login It’s a pretty isolated operation and it’s not usually related to other parties. You authenticate there, get permission (on more sophisticated systems you can have permissions tables) and end up using it. The application should treat this properly. The other tables have nothing to do with the login which is a mechanism of application, the other tables are part of the domain of the problem itself. Unless that table is there for another reason.
In addition in general the more experienced say that it does not make sense to name a table with a prefix tbl
, is redundant information that decreases readability.
It seems to me that you want to create a relationship at all costs even if they’re not needed.
What would that be login?
– Maniero
This login would be to allow the user to have access to the registration of marks, that is, if he does not login, he can not change anything, only view the registered marks
– Rafael
"Login" is an operation, the operation of logging into the system. In this case it does not need a table, the user table already has the necessary data to perform the "login".
– Giuliana Bezerra
But you already have it on the user.
– Maniero
And how I would make the user table relationship with others?
– Rafael
What others? I cannot see any direct relation, at least according to your description.
– Maniero
Usually when speaking in a login table, it is to save the dates that the user has been authenticated, can also be saved information such as source IP and device used, for security purposes
– Costamilam