的背景:
我们有一个主要实体是客户的应用程序.此应用程序中的所有信息均从客户处开始.我们认为如果我们可以将它用于某种分区,那将是非常好的.我们使用Azure SQL数据库作为后端设计了该服务.
我们的表格看起来像这样(为简洁起见,只留下相关部分):
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 );
Run Code Online (Sandbox Code Playgroud)
现在这让我们做了一些疯狂的事情.我们对所有SQL相关内容的入口点始终首先包含以下命令:
USE FEDERATION GroupFederation( FEDERATION_BY_CUSTOMER = 1 ) WITH RESET, FILTERING = ON
Run Code Online (Sandbox Code Playgroud)
在这种情况下这句话:
SELECT * FROM Orders
Run Code Online (Sandbox Code Playgroud)
要么
INSERT INTO Orders ( OrderId ) VALUES ( 10 );
Run Code Online (Sandbox Code Playgroud)
只需要处理给定客户的数据,就可以顺利运行.CustomerId COLUMN将始终从系统函数FEDERATION_FILTERING_VALUE中推断出来;
现在我们可以将所有客户都放在一个数据库中而不会出现问题,并且它们将彼此隔离.如果将来某个时候,其中一个太大了,我们可以在该特定客户ID上拆分联盟,我们不必更改代码中的任何内容来支持它.
哎呀,我们可以让每个客户都在分离的联邦数据库中,而使用它的服务也不会对它有任何了解.
我们对我们的解决方案非常满意,我认为我非常聪明地想出来.直到最近,当微软宣布他们正在使用即将推出的新的azure数据库版本弃用azure联合功能时.在这里和这里阅读更多相关信息.
我希望你能看到我的问题.您认为我的替代方案是什么?您是否使用Azure联盟?您将如何转换?
谢谢.