数据库“所有者”的目的是什么？

今天，在对服务代理问题进行故障排除时，我发现数据库所有者是离开公司的一名员工的Windows登录名。他的登录信息已被删除，因此查询通知失败。

最好的解决方法是让“ sa”成为数据库所有者。我们对其进行了更改，从而清除了队列。

我的（非常基本的）问题：数据库所有者是什么，数据库的目的是什么？

一方面，“ dbo”（用户）和“ db_owner”（固定角色）的数据库概念与另一方面，“数据库所有者”的实例概念之间存在一些混淆。“ dbo”和“ db_owner”通常称为“数据库所有者”。在您要问的是在谈论数据库所有者作为拥有数据库的服务器主体。

理论是这样的：可以授予权限的任何东西都是“安全的”。所有安全资产都有所有者。证券持有人拥有对该证券的绝对控制权，因此不能被剥夺任何特权。实例级别的安全对象归服务器主体（登录）所有。数据库级安全性归数据库主体（用户）所有。校长有两种风格：主要（身份）和次要（成员身份）。默认情况下，服务器级别的安全性由当前记录的主服务器主体拥有。默认情况下，当前数据库主体拥有数据库级别的安全性，但默认情况下，架构所有者拥有的架构绑定对象除外。所有安全对象在创建时都支持AUTHORIZATION子句，以强制使用其他所有者。ALTER AUTHORIZATION 以后可以用来更改任何安全资产的所有者。

由于数据库是可服务器级保护的，因此默认情况下，数据库将由发出CREATE DATABASE语句的主要主体拥有。就是 离职员工的NT登录名。

因此，您的问题实际上是“ 为什么证券需要所有者？ ”。因为所有者是信任的根源。授予，拒绝和撤销对象权限的是所有者。可以设计没有证券持有人的安全系统吗？可能是的，但是必须有某种机制来替换所有者在当前模型中扮演的角色。例如，假设父亲安全产品没有所有者（例如，不是拥有安全产品，而是仅授予原始创建者CONTROL的权限），则有可能创建安全产品并撤消所有人（包括他自己）的访问权限。所有者的要求避免了此问题，因为所有者无法将自己锁定。

创建原始NT登录名拥有的安全性（数据库）的CREATE DATABASE鲜为人知的副作用已经烧掉了很多。每个安全对象的规则都相同，但是一些因素加剧了数据库所有者的问题：

• 其他服务器级别的安全性（端点，服务器角色，登录名）很少使用，移动等。
• 数据库级别的可保护对象通常最终由dbo（数据库主体）或某些其他数据库主体拥有，因此所有者包含在数据库中
• 将数据库所有权默认为NT主要委托人会产生一个容纳问题（所有者是由AD管理的NT SID，并且不随数据库文件一起旅行，NT帐户可以被竖起大拇指等等，等等）
• 最重要的是：数据库所有者有重要的副作用，特别是EXECUTE AS context。后来的问题是烧伤大多数用户的原因。由于Service Broker广泛使用EXECUTE AS（消息传递具有隐式EXECUTE AS上下文，并且队列激活具有显式的上下文），通常是Service Broker用户首先发现此问题。

顺便说一句，Kudos用于调查和解决您的原始问题:)

该数据库owner可以回溯到在SQL Sever 2005中引入（正确）模式之前的时间。

基本上，数据库所有者是数据库的默认dbo数据库所有者（数据库所有者），而数据库本身就是数据库对象。

从SQL Server 2000文档...

的dbo是，已经暗示权限来执行数据库中所有活动的用户。

在早期版本的SQL Server中，当架构不能“拥有”一个对象时（或者应该说所有的对象，表，视图等都归所有者拥有，dbo并且没有其他架构），则必须拥有它的“用户” ...它应该不用说为什么需要某些东西来拥有数据库（否​​则一般来说权限将相当困难。）

因此，从技术上讲，在较旧版本的SQL Server（或升级的数据库）中，它不是“ Foo”表，而是“ dbo.Foo”表……拥有dbo者。

随着SQL Server 2005的问世，您可能拥有架构拥有的数据库对象，例如说您有一个名为“ bar”的架构和一个名为“ Foo”的表bar.Foo...

SELECT * FROM bar.Foo WHERE etc = 'blah`;

棘手的部分在于，创建数据库的用户会自动设置为所有者，这会导致员工流失等问题。

因此，最佳实践是将其更改为sa帐户，或者（以我的经验）更改为可由组织的运营/ IT团队管理的域帐户。

该文章给出了向下突破做事的旧的“主人”的方式，而新的“模式”基于所有权制度之间的差异。

为了了解所有者和架构之间的区别，让我们花一些时间来检查对象所有权。在SQL Server 2000或更早版本中创建对象时，该对象必须具有所有者。大多数情况下，所有者是“ dbo”，也称为数据库所有者。