Проблемы с дизайном базы данных. Таблица (ы) для каждого пользователя

Question

Прежде всего, я знаю, что вопрос обсуждался here и here на stackoverflow. Однако этот случай может быть другим.

Позвольте мне объяснить ситуацию:

Босс хочет меня и мой коллега по разработке веб-приложений, где он может добавить клиентов (читай компании, формы теперь «пользователь»).
У каждого пользователя будет своя частная секция в приложении, где он сможет управлять своим запасом/биллингом/платежами/заказами/... У них даже есть возможность задавать разные модули/пункты меню/представления/.. для своих частных раздел.
Наш босс должен иметь возможность добавлять/удалять некоторые модули/представления/.. путем проверки опции в главном разделе управления.
И так далее ....

Моя первая мысль заключалась в том, чтобы иметь основной модуль для каждого пользователя. Моя идея была отброшена моей коллегой. Он думал, что это слишком много.
Но тогда, когда мы начали проектировать базу данных, он сказал, что хочет иметь большинство таблиц в базе данных для каждого пользователя ...
Я знал, что это была плохая практика и попытался объяснить. Однако он заявил, что было бы небезопасно, если бы мы сохранили все в тех же таблицах. (Если бы нас взломали, у них была бы не только одна компания, это данные, но и данные от ВСЕХ компаний)
Обсуждение заняло некоторое время, и в конце концов его «точка» даже убедила нашего босса его метода ,

Так как я новый парень здесь, я не хотел бы твердо стоять на этом, не зная наверняка если his statement === false

Итак, я хотел бы ваше мнение по этому поводу.

• Как насчет безопасности
• Как о персонализации для каждой компании
• Как об управлении базой данных
• ли кто-нибудь был подобный проект
• Как об использовании различных «модулей» для каждого (как в моей первой идее)
• ... (на самом деле вся информация, чтобы убедить их в норме, но я чувствую, что я должен с отличной альтернативой)

Заранее спасибо

Answer 1

Это в некоторой степени зависит от личного изменения мнения. Но некоторые вещи не являются хорошей практикой. Итак, вот мой взгляд на эти вопросы:

Наличие нескольких «пользователей» в одной таблице не должно представлять угрозу для безопасности.

• Если у кого-то есть доступ к вашему дБ, у него есть все данные, независимо от того, где хранятся.
• Ваше приложение должно обеспечить через отфильтрованные и проверенные условия WHERE, что пользователь может получить доступ только к его строкам, или ваше приложение будет иметь серьезные проблемы с безопасностью на других уровнях до SQL-инъекций.
• Если у вас есть одна таблица для каждого пользователя, у вас будет много проблем в масштабировании вашего приложения для новых пользователей, управлении старыми или удалении их.
• Производительность будет очень плохой, если вам когда-либо понадобится собирать данные от нескольких пользователей
• Максимальное количество таблиц в большинстве БД, в зависимости от многих факторов. Я не знаю, сколько пользователей вам нужно будет хранить, но помните об этом

Решение для разделения пользователей на свои собственные таблицы звучит так, будто вы пропускаете время, необходимое для разработки надежной и надежной модели данных. Это, как правило, приводит ко многим проблемам во время поздней разработки или поддержки вашего приложения. Я бы настоятельно советовал этому.

Правило большого пальца должно всегда состоять в использовании таблицы для каждого типа объекта, а не для объекта объекта.