48

有一次我花了几个小时调试一个简单的 SQL 查询，使用mysql_query()inPHP/MySQL才意识到我错过了表名周围的提示。从那时起，我一直在表名周围使用它。

但是当我在 中使用相同SQLite/C++的符号时，甚至无法识别该符号。令人困惑，是否使用它？标准对它的使用有什么看法？

此外，如果有人能告诉我什么时候使用引号，什么时候不使用引号，那将会很有帮助。我的意思是围绕值和字段名称。

4

2 回答 2

82

SQL 标准（当前版本是 ISO/IEC 9075:2011，分多个部分）没有说明“反引号”或“反引号”符号（Unicode U+0060 或 GRAVE ACCENT）；它不会将其识别为可以出现在 SQL 中的具有特殊含义的字符。

引用标识符的标准 SQL 机制是用双引号括起来的分隔标识符：

SELECT "select" FROM "from" WHERE "where" = "group by";

在 MySQL 中，可能会这样写：

SELECT `select` FROM `from` WHERE `where` = `group by`;

在 MS SQL Server 中，可能会这样写：

SELECT [select] FROM [from] WHERE [where] = [group by];

SQL 标准表示法的问题在于 C 程序员习惯于用双引号将字符串括起来，因此大多数 DBMS 使用双引号来替代标准识别的单引号。但是，当您想要包含标识符时，这会给您带来问题。

微软采取了一种方法；MySQL拿了另一个；Informix 允许单引号和双引号可互换使用，但是如果您想要分隔标识符，则设置一个环境变量，然后您必须遵循标准（字符串使用单引号，标识符使用双引号）；DB2 只遵循标准，AFAIK；SQLite 似乎遵循标准；甲骨文似乎也遵循标准；Sybase 似乎允许双引号（标准）或方括号（与 MS SQL Server 一样——这意味着 SQL Server 也可能允许双引号）。此页面（链接 AWOL 自 2013 年以来 - 现在可在The Wayback Machine中找到）文档记录了所有这些服务器（并有助于填补我的知识空白）并注意分隔标识符中的字符串是否区分大小写。

至于何时在标识符周围使用引用机制，我的态度是“从不”。好吧，不是完全没有，而是只有在绝对被迫这样做的时候。

请注意，分隔标识符区分大小写；也就是说，"from"并"FROM"引用不同的列（在大多数 DBMS 中——参见上面的 URL）。大多数 SQL 不区分大小写；知道使用哪种情况很麻烦。（SQL 标准面向大型机——它希望将名称转换为大写；不过，大多数 DBMS 将名称转换为小写。）

通常，您必须将作为关键字的标识符与您正在使用的 SQL 版本分隔开。这意味着Standard SQL中的大多数关键字，以及您正在使用的特定实现中的任何附加内容。

一个持续的麻烦来源是当您升级服务器时，在版本 N 中不是关键字的列名在版本 N+1 中变成了关键字。升级前运行的现有 SQL 升级后停止运行。然后，至少作为短期措施，您可能会被迫引用该名称。但在事件的一般过程中，您应该避免需要引用标识符。

当然，我的态度因 Informix（这是我主要使用的）逐字接受此 SQL 的事实而受到影响，而大多数 DBMS 会对此感到窒息：

CREATE TABLE TABLE
(
    DATE    INTEGER NOT NULL,
    NULL    FLOAT   NOT NULL,
    FLOAT   INTEGER NOT NULL,
    NOT     DATE    NOT NULL,
    INTEGER FLOAT   NOT NULL
);

当然，为了演示目的而制作如此荒谬的桌子的人应该被绞死，画出来，分成四等份，然后应该留下残渣来修复他们制造的烂摊子。但是，在客户通常设法达到的某些限制范围内，关键字可以在许多情况下用作标识符。这本身就是一种有用的面向未来的形式。如果某个词成为关键字，则现有代码将继续工作而不受更改影响的可能性不大。但是，机制并不完善；您无法创建包含名为 PRIMARY 的列的表，但您可以更改表以添加这样的列。异能是有原因的，但很难解释。

于 2012-05-13T18:07:37.887 回答
0

尾随下划线

你说：

如果有人能告诉我什么时候用引号，什么时候不用引号，那会很有帮助

几年前，我调查了几个关系数据库产品，寻找命令、关键字和保留字。令人震惊的是，我发现了一千多个不同的单词。

他们中的许多人作为“数据库词”出人意料地违反直觉。所以我担心在命名我的表、列等时没有简单的方法来避免与保留字的无意冲突。

然后我在互联网上的某个地方找到了这个提示：

在所有 SQL 命名中使用尾随下划线。

事实证明，SQL 规范明确承诺绝不在任何与 SQL 相关的名称中使用尾随下划线。

由于受版权保护，我不能直接引用 SQL 规范。但是5.2.11 <token> and <separator>来自 ISO/IEC 9075:1992 的假定草案的部分，数据库语言 SQL ( SQL-92 ) 说（用我自己的重新措辞）：

在 SQL 规范的当前和未来版本中，没有关键字以下划线结尾

➥ 虽然奇怪地在没有讨论的情况下被放入 SQL 规范中，但对我来说，这个简单的语句尖叫着“用尾随下划线命名你的东西以避免所有命名冲突”。

代替：

  • person
  • name
  • address

…利用：

  • person_
  • name_
  • address_

自从采用这种做法后，我发现了一个很好的副作用。在我们的应用程序中，我们通常具有与数据库对象（表、列等）同名的类和变量。因此，在引用数据库对象与引用应用程序状态（类、变量）时，会出现固有的歧义。现在上下文很清楚了：当在名称上看到尾随下划线时，数据库被明确指出。无下划线表示应用程序编程（Java 等）。

有关 SQL 命名的进一步提示：为了获得最大的可移植性，请在 words 之间使用全小写和下划线，以及尾随下划线。虽然 SQL 规范要求（不建议）实现以全大写形式存储标识符，同时接受其他大小写，但大多数/所有产品都忽略了这一要求。因此，经过大量阅读和实验，我了解到带有下划线的全小写字母将是最便携的。

如果在单词之间使用全小写、下划线和尾随下划线，您可能永远不需要关心用单引号、双引号、反引号或括号括起来。

于 2021-05-01T23:49:33.010 回答