简单问题 SqlServer中的dbo是啥东西

Posted 2023-05-08

如题,经常看见比如select * from dbo.UserInfo 这样的句子，用了好长时间Sql才发现dbo不知道是什么意思，也不是角色也不是Sql用户，请朋友们帮忙解答。
问题补充：这个dbo不用好象也没什么关系，不知道具体是什么东东

DBO是每个数据库的默认用户，具有所有者权限，即DbOwner

通过用DBO作为所有者来定义对象，能够使数据库中的任何用户引用而不必提供所有者名称。
比如：你以User1登录进去并建表Table，而未指定DBO，
当用户User2登进去想访问Table时就得知道这个Table是你User1建立的，要写上User1.Table，如果他不知道是你建的，则访问会有问题。
如果你建表时把所有者指给了Dbo，则别的用户进来时写上Dbo.Table就行了，不必知道User1。
不光表是如此，视图等等数据库对象建立时也要如此才算是好。

建表、存储过程、视图等数据库对象时，其对应的所有者是创建它的用户。则除了该用户其他登录用户要引用这些东东时，都要加上前缀，很是麻烦。而且，程序因此易出错，你查来查去问题确出在这，浪费你时间。 参考技术A 你好，我的理解是：
表名Userinfo前的dbo不是用户名，而是模式名，只不过这个模式名恰好也叫做dbo。
在sql server数据库中，凡是能够正常登陆系统时使用的登陆账户都会绑定一个数据库用户；或者说在sqlserver中每个数据库用户都对应一个sqlserver管理软件的登陆账户。
假设以windows身份验证登陆进去之后，新创建一个数据库，在创建完数据库之后会将dbo这个默认用户同时创建完毕，并且这个dbo用户拥有一个默认的模式，模式名就叫做dbo。
在创建表的时候如果不特别指定模式，就默认在dbo下建表。
如果在建表的时候显示指定在某个模式下，那么这个表前面就会出现特定模式名.表名。
在安装sqlserver数据库的时候，选择了windows身份验证时，那么在安装时添加的用户就可以拥有了超级管理员的权限，一般用这个超级管理员登录sqlservermanagement studio之后，可以新建数据库（可以使用sql语句，可以使用鼠标点选的方式），新建数据库时系统会默默的新建一个名字叫做dbo的用户，这个用户有默认的拥有一个dbo的模式。这时这个超级管理员就完成了和默认用户dbo的绑定映射，并且当前建表都在用户dbo的默认模式dbo下。
下次再用windows的当前账户登录的时候，就会使用新建时完成的映射操作。
如果在新建数据库用户，还要考虑到存取控制等权限操作。详细情况咱们可以讨论。
总之是几个概念的区别：
数据库，数据库用户，管理系统的登陆账户（有可能是系统的管理员账户），模式，基本表，视图，索引，角色，权限等的区别。
同一个数据库下不同用户间的模式名不可以重复，这是我实验得到的结果，不知道是不是准确。模式实际上就是一个表的命名空间。
欢迎交流。 参考技术B dbo是sqlserver中最垃圾的东西了，也是微软一直是单用户产品的表现

用键值存储中的索引模拟数据库表的最简单方法是啥？

【中文标题】用键值存储中的索引模拟数据库表的最简单方法是啥？

【英文标题】：What is the easiest way to simulate a database table with an index in a key value store?用键值存储中的索引模拟数据库表的最简单方法是什么？

【发布时间】：2011-01-17 09:31:27

【问题描述】：

用键值存储中的索引模拟数据库表的最简单方法是什么？键值存储没有范围查询和有序键。

我要模拟的东西（按优先级排序）：

创建表 添加列 创建索引 根据主键查询 基于任意列的查询

【问题讨论】：

模拟什么方面？ SQL 兼容性？性能品质？只是根据整数主键获取正确的对象？

可以以高性能方式实现的任何方面。

你的问题不是很清楚，你的“澄清”没有澄清任何事情。回答@MB 的 cmets 会让你得到更好的回应。

谢谢，我现在已经扩展了问题

键值存储通常是无模式的“键+值”存储。表的列和索引是非常多的 RDBMS 结构。索引只是提供另一个键来访问您的值。

【参考方案1】：

如果您使用Redis（一种支持字符串、列表、集合等的高级键值存储），那么这很容易。我已经开发了一个C# redis client，它对存储 POCO 的数据模型具有原生支持。 OrmLite 可以使用这些完全相同的 POCO 将其存储在 RDBMS 中。

顺便说一下 Redis 速度很快，我有一个 benchmark，它可以在 1.2 秒内存储和检索整个 Northwind 数据库（3202 条记录）（在 3yo iMac 上的 UnitTest 中运行）。

我以两种方式存储实体

不同的实体，我将类类型名称和主键结合起来创建一个唯一键，例如urn:user:1 然后我维护一组单独的主键（在 Redis 集中）来跟踪我的所有实体，使用如下键：ids:user 在 Redis 服务器端列表中 - 它的行为非常类似于支持分页的表，使用如下键：lists:user

【讨论】：

我过去使用过 Redis，是的，它的速度非常快，我喜欢它，尤其是它具有的所有范围、集合和原子（incr 和 decr）操作。只是现在我正在处理一个在动态可扩展数据库 (Riak) 中存储数十亿条记录的系统，所以 Redis 不太适合这个，因为一切都必须适合内存

实际上 redis trunk 包含一个 VM，它允许您仅使用 1.6GB 内存来存储 1000 万个密钥（具有任何大小的值），同时仍然保持极快 - 请参阅：antirez.com/post/redis-virtual-memory-story.html

是的，我看到了，非常酷！！事实上，即使是 Riak 也有基于 Redis 的后端。虽然它仍然无法扩展到数十亿条记录，但非常好。

数十亿条记录不是硬件问题吗？我们有 64GB RAM 的入门级戴尔服务器。 64GB ~= 400M 密钥。所以 3 台服务器 = 12 亿条记录。使用具有一致哈希的客户端，你就在那里。

是的，这是一种可能性。但是，一旦您开始在集群上运行 Riak 范围查询和有序列表，您就必须执行分布式合并和类似的事情，并且性能下降 1000 倍（我已经尝试过）。我建议尝试一下。在另一个项目中，我们按照您的描述进行了操作，但我们有九台服务器（数据的 3 个副本）。我们最终对所有索引和范围查询进行了手工编码，因此它们最终在集群上工作，因为 Redis 还不支持这些。回想起来，我们应该在那个项目中使用 MongoDB

【参考方案2】：

使用哈希表或字典。如果您想要唯一的键值，您可以使用 GUID 或哈希码。

【讨论】：

你的意思是主键的hastable吗？字典适合放在哪里？

事实上，我认为哈希表可能更适合您。字典只是另一种可能的选择。

【参考方案3】：

键值存储应支持对键进行排序和对键的范围访问。

那么你应该创建两个字典：

id -> payload

和

col1, id -> NULL

，其中payload 应包含数据库表将包含的所有数据，第二个字典的键应包含第一个字典每个条目中(col1, id) 的值。

【讨论】：

我使用的键值存储不支持键排序或范围访问。

另外，你能改一下答案吗，我不明白关于字典的部分。还有什么是 col1？