That depends on what you want, I imagine three situations:
Customers can schedule schedules, being the responsibility of the application to check if that time is valid and available. In this case there was no user table, the access data would be in the client table. The list of who will cut the client’s hair will be on the dial table, the customer will be who is connected and the choice of barber can be the customer or a random detre available
The barbers are responsible for scheduling the times, in this case the validation of the times is important but not essential as in the previous option, also it is not necessary a user table, the access data would be in the barber table. The list of who will cut the hair of the customer will be in the table marking, the customer will be selected and the barber will be the one who is logged in or else the barber will be able to choose some other colleague, if it is busy at the moment
Those who register the data are not customers, nor (at least not necessarily) a barber (maybe a receptionist) or you just want to have a single user so the system is not open. In this case when marking a cut, the user will choose the barber and the customer:
But it is not necessary any relationship between the user table and the others, maybe it is useful to save who marked what, in this case may even have a relationship between users and tags
If you have more than one type of employee, for example, barbers and receptionists, maybe you should have a single table (employee) instead of two (user and barber), this being with a function column, position or something like that
If it is a system where there will be users who will register the data of their trades, it is necessary that the barber tables and customers are related to users, but the same need not be related to markings (although it facilitates some searches), if fetching a user’s markings can be done through the barbers table
This is because a user cannot read, register, change or delete data from other users. Imagine having 100 clients on your system, and suddenly switching to 0 or having 1000 more with exactly the same data polluting the screen and making reports have wrong data
If a table can only be seen by the user himself then yes, it has to have a reference to which user it belongs. The question is: will both barber and client be users? If so, how do you plan to associate them?
– Woss
the barber table will have the information concerning the barber, the same way the client, the table marking will have the key connecting barber and client, containing the scheduled time, the day etc... The user is the one who will have the permission to access the program and do the management. Will this user table also have to be associated with all the others? Remember, only the user will enter the system, the person who wants to cut hair not.
– João Victor Nóbrega
So user, barber and customer are independent things? How will you define which user belongs to the relationship? The one who register?
– Woss
exactly, the one who registers. The user is the one who registers, he q will be responsible for registering the barbers and customers.
– João Victor Nóbrega
That question didn’t make much sense to me. By default nothing is connected to anything, unless you make a query that calls two interconnected tables.
– Fusseldieb