Структура базы данных для обработки нескольких учетных записей (мультиарендная архитектура данных)?

Question

Всегда легко написать программное обеспечение, которое обрабатывает одну сущность. Однако разработка программного обеспечения для обработки нескольких счетов/компаний требует должной осмотрительности.

В настоящее время я провожу предварительное исследование схем баз данных, которые обрабатывают несколько учетных записей/компаний, и я спрашиваю, можете ли вы поделиться веб-страницей или программным обеспечением с открытым исходным кодом, демонстрирующим правильную схему?

Редактировать:Мне удалось найти соответствующую терминологию для этого, которая называется Multi-Tenant Data Architecture. Полезная статья Microsoft, описывающая подход:http://msdn.microsoft.com/en-us/library/aa479086.aspx

Спасибо.

Answer 1

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

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

Использование какой-либо устоявшейся схемы может сэкономить вам массу усилий, но именно эти усилия гарантируют хороший результат. Хорошая структура базы данных возникает из ответа на ВСЕ вопросы: «Может ли сотрудник работать в более чем одном подразделении?» «Всегда ли покупки относятся на счет одного отдела или стоимость может быть распределена?» «Нужно ли нам отслеживать более одного утверждения для переназначения сотрудника?» Это может продолжаться вечно, но если вы этого не сделаете, ваша система будет постоянно разочаровывать пользователей и потребует бесконечных изменений.