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

Question

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

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

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

Благодарю.

Answer 1

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

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

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