Архитектура данных многоуровневых данных

Question

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

Мы планируем провести это ASP.Net MVC4/SQL Server 2008 приложение в некоторых хостинг-провайдера, как winasp.net и т.д. (все же решить)

Business Model Diagram

Есть много уровней пользователей, как суперадминистратор , Администратор Арендатора, Обслуживание Клиентов, Врачи описаны в вышеуказанных фото.

Для достижения этой цели в качестве модели базы данных, мы выбрали Shared Database with Shared Schema подход, упомянутый в MSDN Multitenant Data Architecture

Mean мы добавили столбец был сделан TenantId in each table

Наша общая база данных & разделяет решение схемы на основе ниже

1. Количество арендаторов (50 +)

2. Легко разделить общие метаданные между арендаторами

3. Перемещение большого арендатора (один/два) в отдельном случае, если арендатор имеет больший объем данных

Мы в настоящее время ведется, и мы до сих пор боятся ниже вопросов для решения

1. Data Security -> Everytime необходимо пройти/проверить TenantId

2. резервное копирование для одного жильца -> Нужно написать запрос SQL для резервного копирования и принимая во внимание внешний ключа/автоматическое приращение является головной болью при создании резервной копии

3. объема данных. Единая база данных хранит все данные арендатора, запрос данных медленно

4. Indexing (Не уверен, нужно ли нам индексировать все колонки TenantId в каждой таблице, так как она включает в себя всего ГДЕ

Есть и другие варианты, такие как

• Единая база данных/арендатор
• Общая база данных, отдельная схема

Также This Article добавил еще некоторые подходы

Мы хотели бы получить некоторые рекомендации/лучший дизайн для нашего текущего проекта.

• Новый подход соответствует выше бизнес-схема

• администратор/клиент пользователь услуг арендатор должен быть в состоянии видеть суб-арендаторов записи

• Запрос performamce

• Общий обмен метаданных между арендатором

• Наниматель Конкретные мета данные

• Арендатором Конкретные поля данных (по желанию)

• Простое резервное копирование

Answer 1

Кажется мне, что вы должны пересмотреть свое решение иметь общую базу данных. Если у вас есть требование строгого разделения данных из-за конфиденциальности, чем у вас должны быть отдельные базы данных.

Indexing (Не уверен, нужно ли нам индексировать все колонки TenantId в каждой таблице,
, поскольку она включает в себя всего ГДЕ

Да, вы должны проиндексировать TenantId в каждой таблице и включить его во всех запросах.

Кроме того, похоже, что вы решили использовать SQL Server, прежде чем анализировать требования. Вероятнее всего, существуют более естественные решения для хранения данных с несколькими пользователями, т. е. RavenDB, резервное копирование намного проще. t, чтобы начать обсуждение nosql и т. д. - просто предлагая, чтобы начать с требований и выбрать соответствующую технологию позже.