Нужна помощь в разработке схемы базы данных для приложения SaaS

Question

Я разработчик и никогда не работал над БД до (проектирования БД). Я разрабатываю базу данных для системы управления сотрудниками, которая представляет собой приложение Node.js + Express с использованием MySQL в качестве базы данных.

У меня уже есть необходимые таблицы, отсортированные по столбцам, но есть еще мало неизвестных, с которыми я имею дело. Это мой план, и мне нужен ваш вклад.

1. Конечные пользователи, использующие это приложение, будут небольшими компаниями среднего размера. Компании не будут делиться таблицами в базе данных. Поэтому, если есть таблица с именем EmployeeCases, я планирую создать новую таблицу EmployeeCases для каждой существующей компании или новую, которая зарегистрируется для этого приложения. Я планирую назвать таблицу EmployeeCases_989809890, где «989809890» будет идентификатором компании (или идентификатором клиента). Поэтому, если у нас есть 3-4 компании, которые зарегистрировались для нас, тогда все таблицы (по крайней мере, те, которые использует компания) будут воссозданы и названы TableName_CompanyId. Мои вопросы, это хороший способ пойти? Есть ли способ лучше?

2. Все данные сотрудника хранятся в таблице Employee, включая их логин и пароль. Теперь каждая таблица Employee в БД будет называться Employee_CompanyId (согласно моему плану выше). Мой вопрос заключается в том, когда сотрудник регистрируется, как я узнаю, к какой таблице Employee необходимо выполнить запрос? Или мне нужно удалить логин из таблицы Employee и создать универсальную таблицу «Пользователи», где будут храниться все сотрудники? Таблица Users также будет иметь CompanyId как один из ее столбцов, и я буду читать CompanyId оттуда, который будет использоваться для запроса других таблиц.

Любые ссылки, веб-сайты или блоги на этот тип дизайна будут оценены.

Спасибо.

Answer 1

Я не рекомендую этот подход, я думаю, вы должны либо:

A) Поместите всю информацию в одних и тех же таблицах и есть столбец compagnyId сортировать их

ИЛИ

B) Есть отдельные базы данных для каждой компании и использовать соответствующую базу данных с помощью кода.

Дело в том, что с вашим подходом вам будет трудно поддерживать приложение, если у вас есть несколько копий одной таблицы с разными именами. Если вы решите добавить столбец в одну из таблиц, например, вам придется написать столько SQL-скриптов, сколько у вас есть экземпляры таблицы. У вас также будет плохое время со всем вашим уникальным идентификатором.

Вот некоторые преимущества/недостатки каждой конструкции:

A) Поместите всю информацию в одних и тех же таблицах и есть столбец compagnyId сортировать их

Преимущества:

• Простой
• Разрешить использование внешнего ключа/ограничений
• Отлично подходит для крест/клиент извлечения данных

Недостатки:

• Не портативный (клиент не может просто уйти с его/ее данных)
• Может восприниматься как менее безопасным (я предполагаю, что вы можете сделать в случае обе стороны)
• Более вероятно, имеют огромные таблицы
• не очень хорошо масштабируются

B) Имейте отдельные базы данных для каждой компании и используйте соответствующую базу данных с помощью кода.

Преимущества:

• Портативный
• может восприниматься как более безопасный

Недостатки:

• Needs больше дисциплины, чтобы следить за всем базам данных
• Нужно идти сериализация того, что входит в ваш HUB (ваше приложение, которое отслеживает, какой клиент получает доступ к этой базе данных) и что входит в базу данных вашего клиента.
• Вам нужна страница для входа в компании (или ваши клиенты указать компанию в поле)

Пример приложения, которые используют этот «два шага входа» является Slack, когда вы входите в вас первым введите домен вашей команды ТОГДА ваши учетные данные пользователя.

0 думаю, Google Apps for Work такой же подход. Кроме того, я думаю, что большинство CRM, с которыми я работал, имеют отдельную базу данных для своих клиентов.

И наконец, я хочу направить вас на this other question on stackoverflow, что связано с интересным примером.

Answer 2

Вы не должны разделить свои таблицы только потому, что компании не будут передавать свою информацию. Вместо этого у вас должен быть столбец companyId в каждой таблице и доступ к соответствующим данным для каждого запроса. Это должно быть реализовано в вашем внутреннем интерфейсе