美国社会保障局正在筹划搭建新的会员平台。据了解，他们现在的平台使用了SQLServer 2012和2014数据库，而在新的平台中，他们计划使用微软最新的SQL Server2016。
社保局的高级DBA BasitFarooq成为了SQL Server2016的首批测试用户，他第一次听说新版本发布的消息就是在微软Ignite大会上。Farooq在第一时间就下载了CTP 2预览版，并在过去的几周当中对其中的新功能改进进行了体验。
根据Farooq的说法，他最关注的一个新特性就是集成了PolyBase，也就是说现在可以直接使用T-SQL来将SQL Server 2016和Hadoop对接起来。“微软在此之前没有提供什么像样的分析工具，在这个版本中，它以PolyBase的形式提供了连接到SQL Server的分析工具。有了PolyBase之后，像社保局这样的用户就不需要再另行采购了。而且你的数据是可以真正存储在服务器上了(之前需要单独的存储)。”Farooq说。
另外一个值得关注的功能就是JSON与R语言的结合，这对于数据科学家来说是非常重要的，他们无需再将代码从数据库中导出来运行R程序了，现在可以直接对服务器数据使用R语言进行查询。
作为DBA，Farooq认为最重要的一个新功能就是性能与安全性的提升。“我们所有会员的数据都需要严格保密，”他说：“因此我们需要特别高级的安全性功能，比如AlwaysEncrypted。目前在社保局，我们使用了一些第三方的安全工具，比如DbDefence数据加密软件。而Always Encrypted可以让数据始终处在加密的状态，即使是在交易处理和查询的阶段。还没有那个关系型数据库产品能够做到这一点。”
此外，SQL Server2016对内存数据的支持也实现了上百倍的提升，包括支持内存索引。Farooq表示，查询数据存储以及实时查询统计可以让所有DBA的工作轻松许多，现在你可以直接看到哪些查询占用率了最多资源，然后根据使用情况进行数据库设计规划。
满足客户需求的SQL Server 2016
美国社保局不是立即拥抱SQL Server 2016的唯一一家客户。随着公开的预览版本发布，许多SQL Server用户都对它跃跃欲试。
数据库咨询顾问Denny Cherry的两个客户就在对SQL Server 2016进行测试，而他本人也与SQL Server 2016产品研发团队有着密切的沟通，并参与到了早期的用户计划项目当中。由于比其他用户更早地接触到了SQL Server 2016，Cherry的一个客户已经计划将新版本数据库投入到生产环境。
“由于微软在之前打下了非常好的基础，所以新版本可以非常快地在用户群体之中铺开。比如，微软下了很多功夫来改进 T-SQL，高可用性以及内存OLTP这些核心功能。这些功能在之前的2012和2014版本当中就得到了很好的验证。”Cherry说。
另外Cherry指出，SQL Server2016中特别值得关注的一个新特性是基于AlwaysOn高可用组的分布式交易报表，高可用组(Availability Group)替代了之前的数据库镜像。Cherry表示，微软收到了大量用户反馈，并将这些建议和想法融入到了SQL Server 2016的开发当中。“你可以看到，SQL Server 2016的许多新功能都是来自于用户的声音。”Cherry说。
SQL Server 2016：行级安全
对于SQL Server，一个常见的批评是，其安全模型只能识别表和列。用户如果希望以行为单位应用安全规则，就需要使用存储过程或表值函数来模拟，然后找一种方法，确保它们不会被绕开。在SQL Server 2016中，那不再是个问题。
实现
SQL Server 2016(及SQL Azure)中的 行级安全 基于一个专门设计的内联表值函数。该函数要么返回一个只包含值1的行，要么不返回结果，这取决于用户访问的行是否是相关行。请看下面的函数：
- CREATE FUNCTION Security.fn_securitypredicate(@SalesRep AS sysname) RETURNS TABLE WITH SCHEMABINDING AS RETURN SELECT 1 AS fn_securitypredicate_result WHERE @SalesRep = USER_NAME() OR USER_NAME() = 'Manager';
这段代码的意思是，当前用户必须是一名经理，或者是一名与记录相关的推销员。该函数没有访问行本身，但用户可以使用参数传入相应的列(比如，SalesRep)。例如：
- CREATE SECURITY POLICY SalesFilter ADD FILTER PREDICATE Security.fn_securitypredicate(SalesRep) ON dbo.Sales WITH (STATE = ON);
实际效果
在使用行级安全时，用户无法看到他们不能访问的行。这就好像在访问表时自动增加一个额外的、安全相关的where子句。
由于其作用像一个where子句，所以有一些局限。例如，如果用户在那个列上使用了全文搜索索引，那么数据就可能泄露。此外，数据库还可能遭受旁路攻击。微软写道：
通过使用精心设计的查询，可以导致信息泄露。例如，SELECT 1/(SALARY-100000) FROM PAYROLL WHERE NAME=’John Doe’ 会让一个恶意用户知道John Doe的工资是10万美元。即使有一个恰当的安全谓词阻止恶意用户直接查询其它人的工资，他也可以在查询返回“除数为0”的异常时确定工资数额。
此外，信息也可能通过统计对象泄露。为了降低风险，查看受保护列统计信息的用户必须是“表的所有者，或者是服务器固有角色sysadmin、数据库固有角色db_owner或db_ddladmin的成员”。
中间层应用程序
截至目前，我们讨论的场景是用户以自己的身份登录。在中间层应用程序中，所有人都共享同一个数据库账户，实现行级安全需要额外的步骤。
对于中间层应用程序，推荐的设计模式是将 CONTEXT_INFO 的值设置为连接打开时用户特定于应用程序的用户id。然后，安全函数就可以引用CONTEXT_INFO的值。例如：
- CREATE FUNCTION Security.fn_securitypredicate(@AppUserId int) RETURNS TABLE WITH SCHEMABINDING AS RETURN SELECT 1 AS fn_securitypredicate_result WHERE DATABASE_PRINCIPAL_ID() = DATABASE_PRINCIPAL_ID('dbo') -- 应用程序上下文 AND CONVERT(int, CONVERT(VARBINARY(4), CONTEXT_INFO())) = @AppUserId; -- AppUserId (int)占4个字节 GO CREATE SECURITY POLICY Security.SalesFilter ADD FILTER PREDICATE Security.fn_securitypredicate(AppUserId) ON dbo.Sales WITH (STATE = ON);
该方法的前提是，用户无法执行任意SQL，因为那会让他们可以随意更改CONTEXT_INFO。
