[_HAWK_]

I am wanting to know the best practice for scalability for the following design.

1 database,
multiple customers,
customers have apps or areas(web pages),
customers store data related to their environments.

In the main table where customers live they each get a unique Id, then for each table where I store specific data I must include this customer id, but I feel happening is the other tables and their related tables must also include this id so it remains theirs. If this is normal it seems fine as far as queries, but I also want to know if this follows best practice - if not what would you use?

[modi123_1]

Yes, if you are dividing people up by IDs and their data then yeah.. you'll need to have that id as a constraint on all tables.

I mean if user A, B, and C all want to put "123" in a table and later edit it you should allow for that. This helps also with keeping odd data from bleeding across accounts.

[_HAWK_]

Yes, that is correct. I am getting more elaborate with tables and data and just wanted to make sure the plan was correct. I am self-taught and would hate to start off with some bad design. Thanks modi!

[modi123_1]

No problem. I have an app that I initially had planned to be flexible with multiple teams (and not bleeding over data), but was told "nope.. only one will use it". Shockingly three months later four other teams wanted it so I had to go back in and shoe horn in that 'team id' on the tables. A pain in the rear if you ask me.