在SQL Server 2005中，Microsoft引入了新的Schema对象。这允许我们将所有者与对象的名称解耦。您可以看到，在以前的版本中，数据库对象的命名约定由四部分组成:Server.Database.Owner.Object。2005年及以后的新命名约定现在是Server.Database.Schema.Object。这是有意义的，特别是因为Oracle一直在使用Schema对象，但在SQL Server中会发生什么升级？让我们看看…
在SQL Server 2000中，如果Fred在“Usaserver”上的“pub”数据库中创建了一个名为“Mytable”的表，则完全限定名为“Usaserver. pub .Fred.Mytable”。这假设Fred不是数据库所有者，并且他具有在数据库中创建表的权限。当Fred离开公司或部门时，问题就会出现，而我们不得不重新命名他的对象，并在引用这些对象的地方更改代码。这也适用于存储过程、视图和函数。我们绕过这一限制的方法是采用一种最佳实践，即由数据库所有者创建所有数据库对象。这将把所有者定义为“dbo”，而不是实际的所有者名称。这样，数据库中的所有对象的所有者都有一个标准的“dbo”标签。例如，在上面的示例中，如果Fred是pub数据库的所有者，则包含四个部分的名称将是usaserver . pub .dbo. mytable。当Fred离开公司时，我们可以分配一个新的数据库所有者，而不需要更改任何代码，因为对象名称将保持不变。它也将保证一个不破碎的的所有权链正如我写在这里的博客以前，是一件好事。但是这种策略的缺点是每个数据库只有一个dbo标签。
新的Schema对象允许我们为数据库创建不同的部分，并且每个模式可以由不同的用户拥有。但是，让数据库所有者创建包括模式在内的所有数据库对象仍然是最佳实践，因为的所有权链特性。可以为模式指定一个有意义的名称来描述其中的对象，例如，HumanResources或Accounting等。通过这种方式，我们可以将模式视为数据库中数据库对象的容器。我们还可以将安全性应用于模式，从而应用于模式中的所有对象，从而提供额外的灵活性。权限继承的新特性遵循新的四部分命名约定:权限从服务器继承到数据库，从模式继承到对象。这意味着我们现在可以在数据库级别设置一次执行权限，而不必像过去那样分别进入每个存储过程。
但是从SQL Server 2000或SQL 7.0升级期间会发生什么呢?因为向后兼容性非常重要，升级过程将为旧版本的每个数据库用户帐户创建一个名称相同的数据库用户帐户和一个模式对象。在上面的示例中，升级之后，您将看到一个名为Fred的新模式对象。这意味着任何应用程序代码或存储过程、函数或触发器中的引用都不需要更改，因为对象名称将保持不变:usaserver . pub . fred . mytable。接下来的问题是，我们应该在升级后继续重命名对象吗?答案是，一个字-不。重命名对象并将它们放入新的模式涉及到搜索所有代码模块并确保指定了新名称。这是大量的工作，大量的错误的可能性，并没有立即的好处。虽然新的Schema对象肯定是一个好东西，但它的好处可以在新设计的数据库中实现，这很好。
升级后的一般策略是:如果它有效，就不要修复它!
干杯
布莱恩
最近的帖子: