MySQL已经流行了非常长时间，已经有一代数据库从业者最初就是从MySQL起接触数据库。再重新了解其他数据库的时候，虽然底层原理很多类似，但是上层实现、接口与使用上还是有非常大的不同。本文，就简单的介绍一下SQL Server中的Schema、dbo概念。

参考阅读：

• Why do table names in SQL Server start with “dbo”?@2013年
• Understanding the Difference between Owners and Schemas in SQL Server@2007年
• dbo User and dbo Schema@Microsoft SQL Docs SQL Server 2019
• Create a database schema@Microsoft SQL Docs SQL Server 2019
• CREATE SCHEMA (Transact-SQL)@Microsoft SQL Docs SQL Server 2019
• Why Use Schemas? 这时一篇延续了11年的关于是否应该使用Schema的争论，所以，你的观点是什么？你的实践经验是什么？

Schema or dbo or Database？

这是一个问题。也有很多人做了很多深入的讨论，关于这一点可以参考这篇文章，以及这篇文章后面的100个评论： Why Use Schemas?

有几个观点吧：

• 使用Schema的想法是”美好的”，但是实际的情况往往并不理想，甚至是还不如统一使用dbo。文章作者说，随着时间推移，他看到的实际情况是，使用了多个Schema之后，往往不同Schema中存储的内容并是逻辑上在一起的，而是由于各种历史原因，各个业务的数据表都会混杂在一起，这时候，由于修改应用的成本太高，大家也往往也不会去移动Schema下的表，去让他们在逻辑上更加合理。所以，基于此，作者并不赞同使用Schema，而是倾向于在需要的时候使用不同的Database去隔离逻辑上没什么关系的数据表。
• 很多的第三方的应用，都是使用一个数据库、一个用户访问所有的数据表，因此Schema方式虽然很理想，但是现实世界并不常用。
• 另一方观点是在于，在一个设计较好的数据库中，Schema可以很好的对不同的数据表进行分组，例如，用户相关的表，库存相关的表，店铺相关的表等。另外，在基于这样设计下，权限系统也会更加好管理。另外，否则可能会使用大量的前缀的方式（例如，user_开头代表用户，shop_开头代表店铺相关业务）来区分这些表，看起来并不整齐，整体的授权管理也会比较难一些。
• 比较多人，认为虽然多Schema的设计，前期是比较理想的，但是随着业务和需求的变化，表的业务属性也会发生变化，按照多Schema设计来说，这时候是需要将表移动到合适的Schema下面，但是因为代码的SQL中都带有Schema，这就到这个”移动”的操作变得异常困难，所以也就会最终一定会破坏当初使用Schema的初衷。
• 很多人认为，所有表放在dbo中，从业务角度来说，其实问题是最少的。
• 有人提到，他这样使用schema，将所有的基础表都放在dbo中，但是某些特殊用户的表或者对象放在特定的schema中。例如，一些特定用途的视图、存储过程等。这样，更加便于权限管理。（个人注：这似乎是一种非常适合schema的场景）
• (Mark Broadbent)提到，相比Oracle数据库的Schema，SQL Server权限系统设计更加面向的是Database，而不是Schema。用户通常都有多个Schema的访问权限。
• Ben Thul提到，在大量存储过程的权限管理过程中，schema应该是非常有效的。这和前面的观点是有一定的相似的。Brent Ozar则认为，权限管理更多是通过用户角色组来管理，就可以了。Ben Thul也反驳到，当你已经有100个存储过程的时候，当写101个存储过程，如果没有schema，那么还是要单独管理这个存储过程的访问权限，这时候如果通过以schema为单位的权限管理，确实是高效的。
• 有来曾经在MSFT PMs相关项目的员工(Clifford Dibble)，回忆schema设计的初衷如下：
  • 在单个数据库中，提供一种命名空间隔离的方式
  • 在使用GRANT语句授权时，大大简化对一组对象进行授权管理
  • 微软公司内部”WinFS”团队需要该功能
  • 与ANSI/ISO SQL有更好的兼容性
  • SQL Server自己需要一个系统使用schema：sys
  • 让用户删除更加简单（有一些明确的客户需要）
  • 允许让角色组作为schema的owner
  • 允许多个用户都有某个特定的默认schema
• vinod jain在2021年给出回答（是的，这个帖子是2010年发的，这个讨论延续了11年）有一定代表性，也是两种观点的一个中间形态：
  • 所有的核心表全部都放在dbo中
  • 其他的辅助功能表都独立放在不同的schema中，例如结构记录变更时用到的临时表和数据、导入导出时的中间表、用户日志表