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

#1 楼

一方面，“ 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用于调查和解决您的原始问题:)

#2 楼

数据库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”，也称为数据库所有者。