Как обращаться с другой организацией с единой БД?

Question

Справочная информация
online information system, с которой пользователь может получить доступ через любой компьютер. Я не хочу реплицировать БД и код для каждого университета или организации.
Я просто хочу, чтобы пользователь ударил по домену, как www.example.com, и войдите в систему.
Для второго пользователя он также попадет в тот же домен www.example.com и войдите в систему. но данные для них разные.
Сценарий
Предположим, что в университете работает 200 сотрудников, 2-й университет - 150 и так далее.
Qusetion

мне нужно иметь отдельную таблицу сотрудников для каждого университета или это нормально, чтобы иметь одну таблицу с колонкой, которая имеет университет ID ли?

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

Каков наилучший подход?

Это то же самое для всей таблицы? Это просто для примера.
Спасибо

Answer 1

Этот подход будет зависеть от данных, требований использования и требований клиента.

1. Используйте интегрированную модель, как предложено duffymo. Это может быть уместно, если каждая организация является частью более крупного целого (т. Е. Все колледжи являются частью государственной коллегии колледжа), а проблемы безопасности в отношении доступа к перекрестным запросам минимальны . Этот подход имеет минимальное разделение между каждой организацией как ту же схему , и отношения «открыто» разделяются. Это приводит к очень простой модели изначально, но может стать очень сложным (с составными FK и правильным использованием таких), если нужны отношения для значений, специфичных для организации, потому что он добавляет другое измерение данных.

2. Implement multi-tenancy. Это может быть достигнуто с помощью неявных фильтров в отношении отношений (возможно, скрытых взглядов и процедур хранения), различных схем или другой поддержки, связанной с базой данных. В зависимости от реализации это может или не может разделять схему или отношения, даже если все данные могут находиться в одной базе данных. При неявной изоляции могут быть скрыты или устранены некоторые сложные ключи или отношения. Изоляция с несколькими арендаторами также обычно затрудняет/невозможно перекрестно запросить.

3. Silo the databases полностью. Каждый клиент или «организация» имеет отдельную базу данных. Это подразумевает отдельные отношения и группы схем.Я нашел этот подход относительно простым с автоматизированным инструментом, но для этого требуется управление несколькими базами данных. Прямой кросс-запрос невозможно, хотя «связанные базы данных» могут быть использованы, если есть необходимость.

Несмотря на то, что это не «один DB», в нашем случае, мы имели следующие ограничения 1) не допускается, когда-либо долю/разоблачить данных между организациями, и 2) каждая организация хочет свою собственную локальную базу данных. Таким образом, наш продукт оказался в силосном подходе. Убедитесь, что выбранный подход соответствует требованиям заказчика.

Ни один из этих подходов не будет иметь проблемы с «тысячами», «сотнями тысяч» или даже «миллионами» записей, если индексы и запросы будут правильно спланированы. Однако переход от одного к другому может нарушить многие предполагаемые ограничения, и поэтому решение должно быть принято ранее.

---

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

Интегрированный подход не обязательно небезопасен - но он по своей сути не имеет встроенной изоляции других конструкций.

Answer 2

Я бы нормализовал его, чтобы иметь таблицы UNIVERSITY и EMPLOYEE с отношением «один ко многим» между ними.

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

Answer 3

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

http://msdn.microsoft.com/en-us/library/aa479086.aspx

Я бы с Арендатором Per Schema, что означает копирование структуры через различные схемы, однако, как вы должны сохранить весь ваш SQL DDL в системе управления версиями, это очень легко скрипт.

Легко заглушить и «утечить» информацию между арендаторами, если все это делается в одной таблице.