Многопользовательская федерация по первичному ключу
Вопрос:
Для многопользовательской базы данных с одним общим доступом - если поле tenantid будет включено в первичный ключ (это создаст составной ключ для прикладной таблицы), а затем кластеризованный индекс, или же tenantid может быть просто включен в кластеризованный индекс и не быть частью первичного ключа - поддерживать будущие возможности лазурной федерации?Контекст / Общие сведения:
Я предпочитаю не делать объединенный (tenantid) частью первичного ключа, потому что я буду использовать EF5 (или даже выпущенные версии) и OData с Web API, и я понимаю, что работа в библиотеках EF и OData станет сложнее с композитными ключами
Я не читаю явно, где мне нужно сделать федеративный ключ частью первичного ключа - только составной ключ
Мне не нужно будет объединяться, чтобы начать, но если мне нужно масштабировать, я бы хотел вариант.
Обратите внимание, что я собираюсь использовать GUID только потому, что федерация не будет принимать столбец Identity в качестве первичных ключей (еще одна длинная тема, которая не относится к этому вопросу)
Пример:
Таблица: Основные ключи клиента: TenantID (GUID) Кластерный индекс: TenantID
С:
Таблица: Первичные ключи клиента: CustomerID (GUID) Внешний ключ (ключи): TenantID (GUID) Кластерный индекс: Customer, TenantID
Или же:
Таблица: Первичные ключи клиента: Клиент, Арендатор (Составной первичный ключ) (GUID). Внешний ключ (ключи): Кластерный индекс TenantID (GUID): Клиент, TenantID.
Ссылка:
Ниже приведен отрывок из Руководства и ограничений федерации Windows Azure...Федеративные таблицы имеют следующие ограничения: Столбец федерации федеративной таблицы может содержать только данные, которые подтверждают член федерации range_low inclusive и range_high exclusive.
Тип данных столбца федерации должен точно соответствовать типу данных, определенному в определении федерации.
Все уникальные и кластеризованные индексы в объединенной таблице должны содержать столбец объединения. Порядок появления столбца федерации в индексе может отличаться от порядкового номера ключа в федерации.
Значения столбца федерации не могут быть обновлены до значений вне диапазона членов федерации.
Столбец федерации не может быть постоянным или непостоянным вычисляемым столбцом.
Индексированные представления не поддерживаются в членах федерации.
Столбцы федерации не могут быть пустыми.
Все ограничения внешнего ключа для объединяемых таблиц должны включать столбец объединения в ссылочной и ссылочной таблицах в один и тот же порядковый номер во внешнем ключе. Справочные таблицы не могут иметь отношения внешнего ключа с объединенными таблицами. Объединенные таблицы могут иметь отношения внешнего ключа со ссылочными таблицами без ограничений.
Вы можете удалить таблицы, созданные с помощью предложения FEDERATED ON, как обычно. Вы также можете использовать ALTER TABLE, чтобы изменить все свойства федеративной таблицы, кроме атрибутов федерации, таких как ключ федерации. Чтобы преобразовать справочную таблицу в федеративную таблицу или федеративную таблицу в ссылочную таблицу, необходимо создать новые таблицы с требуемыми свойствами и удалить существующую таблицу.
Когда таблица помечена как STATISTICS_NORECOMPUTE, операции федерации, такие как SPLIT, не делают недействительной или не пересчитывают статистику. Это может вызвать проблемы плана выполнения после операций повторного разделения, таких как SPLIT.
Федеративные участники не поддерживают свойство удостоверения
Федеративные члены не поддерживают тип данных timestamp и rowversion.
1 ответ
ИМХО, использование Tenantid является внутренним для приложения, чтобы идентифицировать данные, основанные на арендаторе. Следующего будет достаточно
Таблица: Первичные ключи клиента: CustomerID (GUID) Внешний ключ (ключи): TenantID (GUID) Кластерный индекс: Customer, TenantID
Я не вижу каких-либо веских причин для того, чтобы tenantid был частью составного первичного ключа. Более того, через федерацию мы только идентифицируем арендатора и его данные.
Следовательно, вы можете очень хорошо иметь TenantId в качестве внешнего ключа / индекса. Пожалуйста, поделитесь своими мыслями по этому поводу.