我正在研究SQL Server中的多租户工具。我考虑了这里描述的共享数据库，共享模式和租户视图过滤器。唯一的缺点是碎片连接池......
每个http://msdn.microsoft.com/en-au/architecture/aa479086，租户视图过滤器描述如下：
＆＃34; SQL视图可用于授予各个租户访问给定表中某些行的权限，同时防止他们访问其他行。
在SQL中，视图是由SELECT查询的结果定义的虚拟表。然后可以查询生成的视图并将其用于存储过程，就好像它是一个实际的数据库表一样。例如，以下SQL语句创建一个名为Employees的表的视图，该表已被过滤，以便只有属于单个租户的行可见：
CREATE VIEW TenantEmployees AS
SELECT * FROM Employees WHERE TenantID = SUSER_SID()
此语句获取访问数据库的用户帐户的安全标识符（SID）（您记得，该帐户属于租户，而不是最终用户）并使用它来确定哪些行应该被包含在视图中＃34;
考虑到这一点，如果我们有一个存储5,000个不同租户的数据库，那么连接池就完全碎片化，每次向数据库发送请求时，ADO.NET都需要建立新连接并进行身份验证（记住连接池）适用于每个唯一的连接字符串），这种方法意味着你有5,000个连接字符串......
我对此有多担心？有人能给我一些真实世界的例子，说明连接池对繁忙的多租户数据库服务器有多大影响（比如每秒处理100个请求）？我可以在这个问题上投入更多硬件吗？它会消失吗？
思考??
答案 0 :(得分：1)
我的兴趣在于为您的数据库开发一个可靠的API。可扩展性，模块化，可扩展性，会计将是主要原因。几年后，你可能会因为玩SUSER_SID（）而发誓自己发誓。例如，考虑一个帐户管理的多个租户或白标签等情况......
拥有数据访问api，它将负责身份验证。您仍然可以在数据库级别进行授权，但这是一个完全不同的主题。拥有用户和组织，并授予他们对租户的权限。
对于大型项目，你仍然会发现每个大玩家拥有一个数据库会更好。
我看到我没有回答关于碎片化连接池性能的主要问题，但我确信有许多有效的论据不会走这条道路。