四、 总结 表格3包含可用于SQLCLR程序集的三种权限集的总结，以及SQL Server为每种权限集提供的保护类型。
· 代码存取安全是在代码内CLR托管的许可权集。
· 编程模型限制是指宿主保护属性，以及是否代码能够使用静态技术。
· 要求确认指指，当你使用CREATE ASSEMBLY语句安装它时是否SQL Server验证代码存在相对的安全性。
· 调用本机代码指示，是否代码能够调用Win32 API或对外部组件作一种平台调用。
表格3:权限设置总结。
权限集
| 保护类型 |
SAFE |
EXTERNAL_ACCESS |
UNSAFE |
| 代码存取安全 |
仅执行 |
执行和受限存取外部资源 |
不受限制 |
| 编程模型限制(主机保护属性) |
是 |
是 |
无 |
| 要求确认 |
是 |
是 |
否 |
| 调用本机代码 |
否 |
否 |
是 |
如你所见，只要你把你的代码限制为SAFE或EXTERNAL_ACCESS，SQL Server就能够提供一种对保护数据安全和服务器稳定性的SQLCLR代码的良好包装。
下面是一个考察你对于SQLCLR安全的理解的测试：
· 可以使用一个常规的ADO.NET连接串来存取另一种数据库（或者是一个Oracle或者是一个Access数据库）吗？
· 假定你现在已经了解访问外部资源，存取一个Oracle数据库的程序集需要具有什么样的SQLCLR权限集级别？
在继续阅读之前，请认真地考虑一下这两个问题吧。
提示 .NET框架中所包含的唯一的托管数据库提供者是System.Data.SqlClient。
注意，这个程序集必须被安装为UNSAFE。为什么呢？因为该代码必须使用System.Data.OleDb对象。因为这些是基于COM的对象（这意味着是非托管代码），所以程序集需要被安装为UNSAFE-因为这是能够存取非托管代码的唯一的级别。
你可能认为这是微软的与Oracle交互的方式。其实，答案是，对于访问一个微软Access数据库也是一样的，因为它也是基于OLE DB和相应的非托管代码。
我将在此斗胆说一句：UNSAFE代码永远不应该用在一个生产服务器中。除非它是能够被完全观察的代码和经过严格校验以验证它不会危害服务器；否则，你无法用一切办法来足已保证它是安全的。尽管我不排除存在关于UNSAFE代码的合法使用，但是我还是要深思熟虑到底是什么样的代码值得这样一冒险。我通常感到，对于使用扩展的存储过程也存在相同的问题，这一样存在冒险性且必须以复杂的C++代码来编写。
至此，我可以说，任何允许UNSAFE代码被安装到一个生产服务器的DBA一般都应该是一个DBA高手而不是一个普通的DBA。而且，我认为，作为一名经常与DBA交流的开发人员，他们中的大多数都是高手！
但是，SAFE代码不会比一个T-SQL存储过程带来更大的危险性，而且，当你需要存取外部资源时，EXTERNAL_ACCESS是一种合理的妥协。因此，你可以不必考虑对于未知内容的畏惧，而只需让SAFE代码加入到你的数据库中好了。然后，当它对于数据库、应用程序及用户来说是重要的情况下，再考虑EXTERNAL_ACCESS代码问题。总之，在使得这一类代码安全和可靠方面，微软的确做了一件好事情。
