我想知道是否有问题，如果表或列名包含大写字母。有些东西让我相信当一切都保持小写时，数据库的麻烦会更少。真的吗？哪些数据库不喜欢表名和列名中的任何大写符号？
我需要知道，因为我的框架会从 ER 模型自动生成关系模型。
（这个问题不是关于它的风格是好是坏，而只是关于它是否是任何数据库的技术问题）
【问题讨论】：
据我所知，使用大写和小写都没有问题。使用小写约定的原因之一是使用小写表和列名以及大写 sql 关键字的查询更具可读性：
SELECT column_a, column_b FROM table_name WHERE column_a = 'test'
【讨论】：
select COLUMN_A, COLUMN_B from TABLE_NAME where COLUMN_A = 'test'
select FIRST_NAME, LAST_NAME from NAMES where FIRST_NAME = 'Alik' :)
对于我所知道的任何数据库引擎来说，在您的表或列名称中包含大写字母都不是技术问题。请记住，许多数据库实现使用区分大小写的名称，因此请始终使用与创建它们相同的大小写来引用表和列（我说的非常笼统，因为您没有指定特定的实现）。
对于 MySQL，这里有一些关于它如何处理标识符大小写的有趣信息。您可以设置一些选项来确定它们在内部的存储方式。 http://dev.mysql.com/doc/refman/5.0/en/identifier-case-sensitivity.html
【讨论】：
SQL-92 标准规定标识符和关键字不区分大小写（根据SQL 标准指南第 4 版，日期/达尔文）
这并不是说特定的 DBMS 不是 (1) 损坏的，或 (2) 可配置的（损坏的）
从编程风格的角度来看，我建议对关键字和标识符使用不同的大小写。就个人而言，我喜欢大写的标识符和小写的关键字，因为它突出了你正在操作的数据。
【讨论】：
select FIRST_NAME, LAST_NAME from NAMES where FIRST_NAME = 'Alik' :)
SQL 标准要求标识符以全大写形式存储。请参阅 SQL-92 的第 5.2.13 节，引用自另一个问题的草稿副本in this Answer。该标准允许您使用小写或混合大小写的未定界标识符，因为 SQL 处理器需要根据需要进行转换以转换为大写版本。
这个要求大概可以追溯到 SQL 的早期，当时大型机系统仅限于大写英文字符。
许多数据库在标准上忽略了这一要求。
例如，Postgres 正好相反，将所有未加引号（“未定界”）的标识符转换为小写——尽管 Postgres 在其他方面比我所知道的任何其他系统都更接近标准。
某些数据库可能会在您指定的情况下存储标识符。
通常这不是问题。几乎所有数据库都会从标识符使用的大小写到数据库存储的大小写进行不区分大小写的查找。
偶尔会出现奇怪的情况，您可能需要在其存储的大小写中指定标识符，或者您可能需要指定全大写。这可能发生在某些实用程序中，您必须在通常的 SQL 处理器上下文之外将标识符作为字符串传递。很少见，但是把它藏在脑后，以防有一天你在使用一些不寻常的工具/实用程序时遇到一些神秘的“找不到表”类型的错误消息。曾经发生在我身上。
如今的常见做法似乎是使用所有小写字母并用下划线分隔单词。这种风格被称为Snake case。
使用下划线而不是Camel case 有助于如果您的标识符曾经全部显示为大写（或全部小写），从而在没有单词分隔的情况下失去可读性。
额外提示：SQL 标准（SQL-92 第 5.2.11 节）明确承诺永远不会在关键字中使用尾随下划线。因此，请在所有标识符后面添加一个下划线，以消除意外碰撞的所有担忧。
【讨论】：
据我所知，一个普通的 L.A.M.P.设置它并不重要 - 但请注意，Linux 上托管的 MySQL 区分大小写！
为了保持我的代码整洁，我通常坚持使用小写的表和列名称、大写的 MySQL-Code 和混合的大写小写变量 - 像这样：
SELECT * FROM my_table WHERE id = '$myNewID'
【讨论】：
我对字段名使用帕斯卡大小写小写的表名（通常）如下：
students
--------
ID
FirstName
LastName
Email
HomeAddress
courses
-------
ID
Name
Code
[etc]
为什么这么酷？因为它是可读的，而且我可以将其解析为：
echo preg_replace('/([a-z])([A-Z])/','$1 $2',$field); //insert a space
现在，这里是表格的有趣部分：
StudentsCourses
--------------
Students_ID
Courses_ID
AcademicYear
Semester
注意我把 S 和 C 都大写了？这样他们就指向了主表。您甚至可以编写一个例程来以这种方式逻辑解析数据库结构并自动构建查询。因此，当它们是 JOIN 表时，我在表中使用大写字母。
类似地，将此表中的 _ 视为 -> 为：Students->ID 和 Courses->ID 不是 student_id - 而是 Students_ID - 字段的同源词与表的确切名称匹配。
使用这些简单的约定可以生成一个可读的协议，它可以处理大约 70% 的典型关系结构。
【讨论】：
table_name2_id 的table_name 指向table_name2 上的id。这样更好，因为您不必担心“StudentID”中的“ID”之类的首字母缩略词。
无论您使用什么，请记住 Linux 上的 MySQL 是区分大小写的，而在 Windows 上是不区分大小写的。
【讨论】：
现代数据库无法处理大写或小写文本。
【讨论】：
例如，如果您使用的是 postgresql 和 PHP，则必须像这样编写查询：
$sql = "SELECT somecolumn FROM \"MyMixedCaseTable\" where somerow= '$somevar'";
“引用标识符也使其区分大小写，而未引用的名称总是折叠为小写。例如，标识符 FOO、foo 和“foo”在 PostgreSQL 中被认为是相同的，但“Foo”和“ FOO" 与这三个不同。（PostgreSQL 中将不带引号的名称折叠为小写与 SQL 标准不兼容，SQL 标准规定不带引号的名称应折叠为大写。因此，foo 应该等效于 "FOO " 根据标准，不是 "foo"。如果您想编写可移植应用程序，建议您始终引用特定名称或永远不要引用它。)" http://www.postgresql.org/docs/8.4/static/sql-syntax-lexical.html#SQL-SYNTAX-IDENTIFIERS
所以，有时候，这取决于你在做什么......
【讨论】：
PostgreSQL 中混合大小写或大写的列名必须用双引号引起来。如果以后不想担心，就用小写命名吧。
MySQL - 列绝对不区分大小写。它可能会导致问题。假设有人写了“mynAme”而不是“myName”。该系统可以正常工作，但是一旦某些开发人员通过源代码搜索它，他们可能会忽略它，而你们都会遇到麻烦。
【讨论】：
认为这是值得强调的：如果二进制或区分大小写的排序规则生效，那么（至少在 Sql Server 和其他具有丰富排序规则功能的数据库中）标识符和变量名将区分大小写。您甚至可以创建名称仅以大小写不同的表。 （——我不确定上面关于 sql-92 标准的信息是否正确——如果是这样，这部分标准并没有被广泛遵循。）
【讨论】：