Базовая архитектура базы данных для веб-приложения

Question

Я пытаюсь создать веб-систему управления задачами.Я хочу, чтобы разные организации могли иметь доступ к различным спискам задач.Существует два способа настройки архитектуры базы данных:

1. Все задачи для всех организаций хранятся в одной таблице.Записи задач, связанные с организацией X, имеют внешний ключ, сохраненный для идентификационного номера X.
2. Каждая организация получает свою собственную таблицу задач.Таблица имеет префикс для идентификации ее как принадлежащей этой организации.В отдельной таблице хранятся связи между организациями и префиксами таблиц.

Каковы преимущества и недостатки 1. против 2.?Какой из них лучше?Кроме того, я рассматриваю возможность разрешения пользователям отключать определенные атрибуты задач, например, возможность отслеживать, сколько времени вы работали над задачей.Я думал, что лучше всего это сделать, добавив или удалив поля из таблицы задач.Так как разные организации будут иметь разные параметры конфигурации, 2. подойдут ли они для этой цели лучше?

Answer 1

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

Я бы подумал, что лучшим решением будет сделать это управляемым данными со структурой, подобной приведенной ниже:

**OrganisationTable**
ORGANISATION_ID

**TaskTable**
TASK_TYPE

**TasksOrganisationStatusTable**
TASK_TYPE
STATUS (Boolean)
ORGANISATION_ID

**TasksTable**
ORGANISATION_ID
TASK_TYPE
DUE_DATE
etc.

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

Answer 2

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

В этом случае все работает отлично.

Answer 3

Поисковым термином для этого является «многопользовательская база данных» или «многопользовательская архитектура».

Существует краткий обзор и ссылка на полезную статью из этого вопроса StackOverflow .