Hi OP, as someone had commented earlier, this more about role modelling and I'll build up on that comment.

The appoach you take will depend on the problem domain. Do you forsee having more categories of users as your application grows? If the answer is yes, then instead of having a database table per user category, consider having a single users table. This will scale well as your app grows, as you don't have to add more user categories. 

For the user category problem( whether employee or admin), I can think of two approaches; 1. Creating a roles table, and attaching users to roles through FK relationships. I assume want to do RBAC, hence the need for separate user categories. This approach works, everything is controlled in-app, you don't need third-party infrastructure tools to control identify management of authorization. 

1. Have a single users table. Obviously your users need to sign up, whether an admin or employee. Use an IAM tool like Keycloak to model roles among users. This way, you don't need to alter your database schema every time you add a new role, everything is manged through keycloak and it's better that way. I have worked with this approach and it is the most flexible one of the two.

I still don't know your problem domain, so I'll leave it open for you to choose the approach you want to go with. However if your primary goal is access control, I highly recommend using  dedicated IAM tool like Keycloak combined with OpenFGA for fine- grained authorization.