SQL Server 和关键字架构

Posted 2023-03-08

【中文标题】SQL Server 和关键字架构

【英文标题】：SQL Server and Keyword Schemas

【发布时间】：2017-10-18 16:44:11

【问题描述】：

我正在将我们从 MSAccess 后端转换为 SQL Server 后端。

在没有真正考虑关键字的情况下，我们的计划有一个 Admin、Order 和 Address 架构。我一直阅读并被教导，你不应该使用关键字作为架构、函数、存储过程等名称，这样做真的会让你感到沮丧.

如果我打算将始终明确定义我的架构（例如 [Admin].CompanyInformation）作为标准做法，那么使用关键字是否有问题？

【参考方案1】：

再一次，使用模式限定对象名称与使用保留字作为标识符无关。即使您使用模式名称对其进行限定，使用保留字作为名称仍然会遇到问题。示例：

set nocount on;
use tempdb;
go

create table dbo.[table] (id int not null); 
print 'creating dbo.table as a table';
go

-- the next two statements fail
select * from table;
select * from dbo.table;
go

print '';
print 'select from dbo.[table] works**';
select * from dbo.[table];

if object_id('dbo.table') is not null 
   drop table dbo.[table];
go

所以 - 是的，您应该使用架构名称。是的 - 您应该避免使用保留字作为对象名称。做前者并不否定做后者的必要。还有一些你应该知道的对象名称的附加规则——常规标识符的规则是https://docs.microsoft.com/en-us/sql/relational-databases/databases/database-identifiers。

即使您选择不遵守规则，您也可能会使用不是您开发且编写不仔细的软件 - 当遇到不是常规标识符的对象名称时，这些软件将无法正常工作。 THAT 理由是遵守常规标识符规则的最佳理由（其中之一是避免使用保留字作为名称）。

【讨论】：

所以最重要的一点是，如果我打算通过一些第三方软件连接到它，我应该谨慎行事并避免使用保留字，否则如果符合条件，则有没问题。似乎唯一反对它的论点是微软说不要这样做，因为它可能很烦人。我真的不想使用保留字，并且正在尝试提出替代方案，但是我的名称很好地描述了我的架构。你对反对使用保留字的论点有同样的感受吗？？

【参考方案2】：

不，如果您写 [Admin]（不是 Admin），这不是问题。

附：无论如何，您应该始终明确定义您的架构，因为默认架构通常是 dbo

【讨论】：

我完全同意。我的意思是限定模式，而不是仅仅执行“SELECT * FROM CompanyInformation”。我将始终明确限定模式。

我只是在所有不应该使用关键字的地方阅读，但除了会让人头疼之外，如果它们被分隔，使用它们并不重要。

如果你说出你的名字没有问题。在我的公司中，有些表的名称类似于[Accounts->Types?Get]，有些人喜欢它

@Elias 我认为您在这里没有正确使用工作“关键字”。看来您已经在“关键字”和“模式”之间建立了某种联系。最佳实践是使用适当的模式限定任何对象（表、过程、函数等）名称。这与您是仅使用一个架构（如 dbo）还是多个架构无关。

@SMor，我的意思是 [docs.microsoft.com/en-us/sql/t-sql/language-elements/… 由 Microsoft 定义）被用作 [***.com/a/529149/1504882](schema) 名称。