如同在之前版本中的一样，如果对象是在代码运行的同一台服务器上那么你可以省略服务器名称。如果连接打开了同一个数据库那么你可以忽略数据库名称。而如果它是当前用户默认的schema或者是dbo所拥有的，那么你可以忽略schema 名称，因为那是当SQL Server 试图消除一个对象名称的歧义时采取的最后手段的schema。
使用CREATE USER 语句替代sp_adduser 来创建新的用户。这个系统存储过程仍然围绕向后的兼容性，并已被修改了一点来适应新的用户和schemas的分离。sp_adduser 创建了一个schema，它使用相同的名称作为新的用户名称或应用程序角色，并指定这个schema 作为用户默认的schema，模仿SQL Server 2000行动但提供了一个单独的schema。
注意 在使用ALTER AUTHORIZATION 语句时，它可能会导致你拥有一个在我的中的表(反之亦然)。这会导致严重的问题。例如，谁拥有这个表上的触发器，你还是我?底线是它现在能够巧妙地发现schema范围的对象或类型的所有者。这有两个方法：
· 使用OBJECTPROPERTY(id， 'OwnerId')来发现一个对象的真正所有者。
· 使用TYPEPROPERTY(type，'OwnerId')来发现一个类型的真正所有者。
SQL Server 可以使用同义字来帮助保存按键。你可以为任何使用两部分、三部分或四部分完整对象名称的对象创建一个同义字。SQL Server 使用同义字来访问定义的对象，在下面的代码中，History 同义字显示了AdventureWorks数据库中指定的schema.table。SELECT 语句返回了EmployeeDepartmentHistory表的内容。
USE AdventureWorks
GO
CREATE SYNONYM History FOR HumanResources.EmployeeDepartmentHistory
SELECT * FROM History
你还可以为完整的四部分名称定义History 同义字，如下面的代码所示：
CREATE SYNONYM History
FOR MyServer.AdventureWorks.HumanResources.EmployeeDepartmentHistory
使用像这样的完整的四部分名称允许使用从另一个数据库上下文得到的同义字，假设当前的用户具有使用这个同义字和读取表的权限：
USE pubs
SELECT * FROM AdventureWorks..History
还要注意，如果你不提供一个schema名称作为新的同义字名称的一部分，那它将成为默认schema 的一部分。
5. 加密和密钥管理
服务器级别的安全可能是系统管理员最为关注的，但是数据库是一个生产环境中所有活动发生的地方。对于大多数情况，数据库管理员可以让数据库开发人员关注于数据库的细节，只要开发人员是在环境的约束之下。SQL Server 2008提供了大量的特性用于保护数据库。
5.1 数据加密
SQL Server 2000 和之前的版本没有对数据库中存储的数据进行加密的内置支持。为什么你需要对安全地放置在防火墙之后的很安全的服务器上存储在很安全的数据库中的数据进行加密?这是因为有一个出现了几年的重要的安全原则——defense in depth。Defense in depth意味着分层防范，以便即使攻击者突破了你最外层的防御，他们还是需要再通过层层防御才能抵达中心。在一个数据库中，这意味着如果一个攻击者通过了防火墙和服务器上的Windows安全后抵达了数据库，她还是需要作些工作来试图解析你的数据。而且，在数据和隐私受到法律保护的今天，数据需要进行强有力的保护。
SQL Server 2008使用对称和非对称密钥以及数字证书提供了对广泛的数据加密种类的大力支持。最重要的是，它为你管理密钥，因为到目前为止，密钥管理是最难加密的部分。保密秘密绝非易事。
作为一个管理员，你可能至少要管理密钥层级的上层，如图10所示。数据库管理员需要了解服务器级别的服务主密钥和数据库级别的数据库主密钥。每一个密钥保护它的子密钥，而这些子密钥反过来保护它们自己的子密钥，这样在树型结构中传递下去。一个例外就是当一个密码是保护一个同义字密钥或证书的时候，这是SQL Server 让用户管理他们自己的密钥和保证密钥的隐密性的方式。
