How accounts will be modelled in the system is something which needs to be decided on early in the process, as everything else will build on this. Unlike linking users and accounts, this will be transparent to the end user, as it’s just the internal modelling which is affected.
There are 2 types of accounts, which will be referred to as company accounts and client accounts. A company account is what is created for you when you first sign up, if you’re invited into the system, you join the company account of the person who added you. In the context of a project, the company account is the one delivering the project and the client account is the one who the project is being done for. The complexity arises from the fact that a company account can also be a client account, but at the same time, they each have distinct roles and attributes, which gives the following options for modelling the relationships.
Separate accounts for companies and clients
In this case, there would be a separate table for company account and a separate table for client accounts. The benefit of this is there is a clear distinction between the 2 account types and you can have a different set of users depending on the role of that account. The downside is there is a lot of data duplication. The account would have 2 instances, and there would be 2 sets of account/user relations. Also, as the accounts are stored as 2 separate entities, they could have different identifiers, such as names, IDs etc which makes it harder to know if they’re the same account.
Company and Client extend Account
This “simplifies” the previous case, by introducing an extra table. By adding an accounts table, which companies and clients can extend, we no longer have the need for duplicated data. All common data between the 2 account types would be stored in the accounts table and all users will be linked to this table, instead of the company or client account, and then any unique data would be linked to the appropriate account. This would simplify the database side, but could unnecessarily complicate the application.
Company extends Client
This is an extension of the previous idea, but without adding the extra table. Every account will always be either a company or client account, so why not make the base account either company or client, and make the other one extend it. It would make sense to have the base account the client account, as company accounts will need to have extra meta data, as they actually manage the projects.
One account to rule them all
In this case, there would be just one table storing account data, and there would be no differentiation between company and client accounts. The account type will only be distinguished at run time in the application based on the context. This provides the most flexibility, as it would be possible to switch between account types on the fly.
Due to the added flexibility of the last method, this is the method I will be using. It also has the benefit of requiring the least storage in the database as accounts and relations are not duplicated.
