This question may answer itself, but it is also a question of best practices.
I am designing an application that allows users (comapnies) to create an account. Those users are placed in a table “Shop_table”. Now each shop has dynamic data, however the tables would be the same for each shop, like shop_employees, shop_info, shop_data.
Would it be more effective to have a specific table for each shop or would I just link their data by the shop id.
For example:
shop: Dunkins with id:1
shop: Starbucks with id:2
would dunkins have its own dunkins_shop_employees, dunkins_shop_info, dunkins_shop_data tables
and Starbucks have its own starbucks_shop_employees , starbucks_shop_info , starbucks_shop_data
or would i have one table shope_employees, shop_info, shop_data and link by id 1 or 2, etc..
Definitely one table for each entity with a field to identify the company.
If all the companies have the same information there is no need to create tables for each, and if you did your queries will become a nightmare.
Do you really want a load of UNION queries in order to get any aggregate data across companies? You will also have to modify all queries in your DB as soon as another company (and therefore multiple tables) are added.
Define your tables independently, model the entities you want to store and dont think about who they belong to.