尾随下划线

Question

我花了好几个小时在mysql_query()中使用PHP/MySQL调试一个简单的SQL查询，却发现我错过了关于表名的bactick。从那时起，我一直在使用表名。

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

此外，如果有人能告诉我何时使用报价，何时不报价，将会有所帮助。我的意思是值和字段名称。

Answer 1

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似乎遵循标准; Oracle似乎也遵循该标准; Sybase似乎允许使用双引号（标准）或方括号（与MS SQL Server一样 - 这意味着SQL Server也可能允许双引号）。这个page记录了所有这些服务器（并且有助于填补我的知识空白），并注意分隔标识符中的字符串是否区分大小写。

至于何时使用标识符周围的引用机制，我的态度是'永远'。嗯，不是永远不会，但只有在绝对强迫这样做的时候。

请注意，分隔标识符区分大小写;也就是说，"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的列创建表，但您可以更改表以添加此类列。特质是有原因的，但很难解释。

Answer 2

尾随下划线

你说：

<块引用>

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

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

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

然后我在互联网上找到了这个技巧：

<块引用>

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

事实证明，SQL 规范明确承诺永远不会在任何与 SQL 相关的名称中使用尾随 underscore。

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

<块引用>

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

➥ 虽然奇怪地在没有讨论的情况下被扔进了 SQL 规范，但对我来说，这个简单的声明大喊大叫“用尾随的下划线命名你的东西，以避免所有命名冲突”。

代替：

person
name
address

...使用：

person_
name_
address_

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

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

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

SQL标准对反引号（`）的使用有何看法？

2 个答案:

尾随下划线