Фон:
У нас есть приложение, в котором основным объектом является клиент. Вся информация в этих приложениях начинается с клиента. Мы подумали, что было бы очень хорошо, если бы мы могли использовать это для какого-то разделения. Мы разработали службу с базой данных SQL Azure в качестве серверной части.
Наши таблицы выглядят так (для краткости оставлена только соответствующая часть):
TABLE dbo.Orders
(
CustomerId INT NOT NULL DEFAULT( FEDERATION_FILTERING_VALUE( 'FEDERATION_BY_CUSTOMER' ) ),
OrderId INT NOT NULL,
....,
CONSTRAINT PK_Orders PRIMARY KEY CLUSTERED ( CustomerId, OrderId )
) FEDERATED ON ( FEDERATION_BY_CUSTOMER = CustomerId );
Теперь это позволило нам делать некоторые сумасшедшие вещи. Наши точки входа во все, что связано с SQL, всегда сначала содержат следующую команду:
USE FEDERATION GroupFederation( FEDERATION_BY_CUSTOMER = 1 ) WITH RESET, FILTERING = ON
В этом случае это утверждение:
SELECT * FROM Orders
or
INSERT INTO Orders ( OrderId ) VALUES ( 10 );
будет работать без проблем, работая только с данными данного клиента. COLUMN CustomerId всегда будет выводиться из системной функции FEDERATION_FILTERING_VALUE;
Теперь мы могли бы без проблем иметь всех наших клиентов в одной базе данных, и они были бы изолированы друг от друга. Если когда-нибудь в будущем один из них станет слишком большим, мы можем РАЗДЕЛИТЬ федерацию по этому конкретному идентификатору клиента, и нам не нужно ничего менять в нашем коде для его поддержки.
Черт возьми, мы могли бы иметь каждого клиента в отдельной базе данных федерации, и служба, использующая ее, ничего бы об этом не знала.
Мы были очень довольны нашим решением, и я подумал, что придумал его очень умно. Лишь недавно Microsoft объявила, что отказывается от поддержки федераций azure в новых выпусках базы данных azure. Подробнее об этом читайте здесь и здесь.
Надеюсь, вы видите мою проблему. Как вы думаете, какие у меня есть альтернативы? Используете ли вы Azure Federations и как вы собираетесь переходить?
Спасибо.
