Database design issues. Table for each user

Question

First of all, I know that the issue was discussed here and here in stackoverflow. However, this case may be different.

Let me explain the situation:

The boss wants me and my colleague to develop a web application where he can add customers (read companies, form a "user" now).
Each user will have his own private section in the application, where he will be able to manage his account / billing / payments / orders / ... They even have the ability to set different modules / menu items / views / .. for their private section.
Our boss should be able to add / remove some modules / views / .. by checking the options in the main control section.
And so on....

My first thought was to have a core module for each user. My idea was discarded by my colleague. He thought it was too much. But then, when we started creating the database, he said that he wanted to have most of the tables in the database for each user ...
I knew this was bad practice and tried to explain. However, he stated that it would be unsafe if we stored everything in the same tables . (If we were hacked, they will have not only one company, but also data from all companies)
The discussion took some time, and in the end, his "point" even convinced our boss of his method.

Since I'm the new guy here, I don't like to stand firm on this without knowing for sure if his statement === false

So, I would like your opinion on this.

• How about security
• How about personalization for each company.
• How to manage a database
• Does anyone have a similar project
• How about using different “modules” for each company (as in my first idea).
• ... (in fact, all the information to convince them of the order, but I feel that I should come with a great alternative).

Thank you in advance

Answer 1

This is, to some extent, a question of a personal opponent. But some things are not good practice. So, here is my view on these points:

Having more than one "user" in the same table should not be a security risk.

• If someone has access to your db, he has all the data, regardless of what is stored there.
• Your application must ensure through filtered and verified WHERE conditions that the user can access only his lines, or your application will have serious security problems at other levels prior to SQL injection.
• If you have one table for each user, you will have many problems scaling your application to new users, managing old ones, or deleting them.
• Performance will be very poor if you ever have to collect data from multiple users
• The maximum number of tables in most databases depends on many factors. I don’t know how many users you will need to store, but keep that in mind.

The decision to split users into their own tables sounds like you're missing the time it takes to develop a reliable and reliable data model. This usually leads to many problems during the late development or support of your application. I would strongly advise this.

The thumb rule should always be used for the table for each type of object, and not for the object of the object.