Question

我正在寻找一个处理.dbo前缀的高性能默认策略。

我意识到dbo。前缀不仅仅是语法噪音，但是我通过过去8年的基于MS的开发跳过键入dbo。前缀并忽略其功能。

除了存储过程编译锁的性能问题外，在SQLqueries和存储过程中跳过键入“.dbo”还有一个缺点吗？

进一步背景：我的所有开发都是基于中间层服务帐户的集成安全性的Web中间层。

Answer 1

[DBO]。[XXX]

SQL Server引擎总是将查询解析成碎片，如果你不使用前缀肯定会在使用[dbo]之前搜索具有不同用户的类似名称的对象。我建议你遵循前缀机制不仅要满足最佳实践，还要避免性能故障并使代码可扩展。

我不知道我回答了你的问题，但这些只是我的知识分享

Answer 2

大多数时候你可以忽略它。有时你必须输入它。有时当你必须输入它时，你只需输入一个额外的'。'：

SELECT * FROM [LinkedServer].[Database]..[Table]

如果你开始使用额外的模式，你需要开始关注它，你可能在同一个数据库中有两个模式，这两个模式都有同名的表。

Answer 3

主要问题不是安全性，而是名称冲突解决方案，如果您的应用程序将与数据库中使用相同名称的另一个应用程序并排部署。

如果您打包和销售您的产品，我强烈建议您使用架构，以满足您的客户需求。如果你为一个特定的专柜开发，那么就不用担心了。

Answer 4

是的，你可以忽略 - 在大多数情况下 - 如果你从未在（默认）“dbo”架构之外创建任何东西。一个你不能忽视它的地方是在调用一个存储函数时 - 总是必须有“两部分”表示法：

select * from dbo.myFunc

但是，始终使用“dbo”被视为最佳做法。前缀（或其他模式前缀，如果您的数据库有多个模式）。

马克

Answer 5

“然而，我经历了过去8年基于MS的开发跳过键入dbo.prexfix并忽略其功能。”

这是你的答案。如果您的数据库性能良好，那么您可以。最佳实践不会取代实际系统上的实际测试。如果你的表现很好并且维护得很好，你可以把时间花在其他地方，这样你可以获得更好的效果。

Answer 6

在oracle世界工作之后，我建议不要跳过架构声明。现在请记住，7.0之后的SQL Server版本支持每个数据库的多个模式 - 区分它们以确保您正在抓取正确的表非常重要。

如果您可以确保每个数据库永远不会有两个单独的模式命名空间，那么您可以忽略它。 dbo。前缀本身不应该影响性能 - 解析是SQL查询的一小部分，无关紧要。