2

I have a Accounts table in MainDatabase with the following columns:

AccountID | Username | Password | AccountDatabase

And AccountDetails table for SpecificDatabase (SpecificDatabase will be based on the name the employer entered, so it will be dynamic):

AccountID | FirstName | LastName | AccountAccess

So every time a new employer registers, his inputs will be saved in MainDatabase, and simultaneously creating a SpecificDatabase of his own. The problem I am facing is whether the employees for a specific employer will also be saved in the MainDatabase or in the SpecificDatabase.

If I saved the employees in the MainDatabase, I don't have to create a "token" to know what SpecificDatabase the employee belongs to, but MainDatabase.Accounts would end up having many rows. And if I saved the employees in its own SpecificDatabase, I would need to create a "token" in their login details, but maintenance for the SpecificDatabase will be easy (ex. Employer expires, deletion will be easy).

TL;DR

What would be the most efficient way to store employee accounts, in the main database or in its employer's database?

5
  • A database rule is not to have any redundant data.
    – Rick James
    Sep 6, 2017 at 5:25
  • @RickJames What do you mean by redundant data? Sep 6, 2017 at 6:00
  • 1
    I wouldn't store an employers employees in the main database, because of security considerations.
    – John K. N.
    Sep 6, 2017 at 6:31
  • @hot2use So I guess I will be needing a token to determine what database that employee belongs to, or is there another for that? Sep 6, 2017 at 6:39
  • E.g. An employer logs in to the (web-) application and is assigned an id from the main database. Any other request from said session is performed with a separate connection that access the other database.
    – John K. N.
    Sep 6, 2017 at 6:42

0

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Browse other questions tagged or ask your own question.