为什么下划线通常是在SQL表名，而不是骆驼情况下使用[关闭](Why underline is us

在所有的应用程序/例子我已经看到（如WordPress的）。该列的表名称使用下划线，而不是骆驼情况。我想知道是否有一些技术上的不兼容的问题，或者它是一个约定？它是依赖于系统平台（Linux / Windows的）或SQL方言（MySQL和PostgreSQL，DB2，甲骨文，...）。例如，下面的表中我用骆驼情况下，我还没有过任何问题，/它警告！如果我/必须修改我的表，为什么要/必须做什么呢？

是SQL的情况下对表/列名不敏感？怎么样的方言？

CREATE TABLE `testuser` (
  `id` bigint(20) NOT NULL,
  `user_type` varchar(8) NOT NULL,
  `username` varchar(30) DEFAULT NULL,
  `password` varchar(128) DEFAULT NULL,
  `regDate` datetime DEFAULT NULL,
  PRIMARY KEY (`id`),
  UNIQUE KEY `username` (`username`)
) ENGINE=InnoDB DEFAULT CHARSET=latin1;

背景信息的比特：

该（ANSI）SQL标准要求，不带引号的标识符存储在系统目录中的所有大写字母和非带引号的标识符不区分大小写。

根据标准下面的非引用的标识符引用相同的对象（例如，表）： FOOBAR ， foobar ， FooBar （和所有将被存储为FOOBAR在系统目录中）。

下面引用的标识符文献3个不同的对象： "FOOBAR" "foobar" ， "FooBar" 。

几乎所有的数据库管理系统与非引用的标识符是不区分大小写的要求，至少符合。除了MySQL和SQL Server作为据我所知 - 既可以配置为区分大小写即使对于非带引号的标识符。我不知道SQL Server的默认行为是什么，但（如达在他的评论中指出的，这取决于所使用SQL Server的排序规则）。

MySQL是更加令人困惑的是它的行为取决于多个配置设置，存储引擎和文件系统的组合。所有其他DBMS我知道关于跨所有平台和设备的行为是一致的。

PostgreSQL的符合的情况下，灵敏度，但它折叠一切为小写。

所以，有了这些规则，我觉得用下划线“传统”的命名约定从对象名称都存储在大写的事实造成的。得到“可读”的名字的唯一方法是在名称的重要组成部分用下划线分开。

因为它是保留大小写（类似的方式在NTFS下的Windows工作），所以它不折的名字什么的SQL Server更是非标准。所以，当它存储在系统目录中（但默认情况下不区分大小写）不更改名称的情况。出于这个原因，你会发现人们使用驼峰更多的时候则如在Oracle环境在Microsoft环境中工作。