mysql数据库标识符大小写_关于数据库：我应该写表名和列名总是小写吗？

我想知道表或列名是否包含大写字母是否有问题。 让我相信，当一切都保持小写时，数据库的麻烦会减少。 真的吗？ 哪些数据库不喜欢表名和列名中的任何大写符号？

我需要知道，因为我的框架是根据ER模型自动生成关系模型的。

(这个问题不是关于样式的好坏，而是关于任何数据库的技术问题)

您甚至认为可能存在什么样的"麻烦"？

麻烦= DBMS不接受表名和列名的大写字母。

据我所知，使用大写和小写都没有问题。使用小写字母约定的原因之一是，使用小写的表和列名称以及大写的sql关键字可以使查询更具可读性：

SELECT column_a, column_b FROM table_name WHERE column_a = 'test'

我认为突出显示关键字很奇怪。 我更喜欢突出显示业务数据，这更重要。 而且，使用一个好的SQL编辑器，您已经获得了彩色的关键字。 他们的上壳体将加倍突出显示。

例如，我认为以下内容更清楚：select COLUMN_A, COLUMN_B from TABLE_NAME where COLUMN_A = test

或更合乎逻辑的东西：select FIRST_NAME, LAST_NAME from NAMES where FIRST_NAME = Alik :)

SQL-92标准指定标识符和关键字不区分大小写(根据SQL标准第4版指南Date / Darwen)

这并不是说特定的DBMS既不是(1)损坏的，也不是(2)可配置的(并且损坏的)

从编程风格的角度来看，我建议对关键字和标识符使用不同的大小写。就个人而言，我喜欢大写标识符和小写关键字，因为它突出显示了您要处理的数据。

示例：select FIRST_NAME, LAST_NAME from NAMES where FIRST_NAME = Alik :)

对于我所知道的任何数据库引擎，数据库在表名或列名中都使用大写字母不是技术问题。请记住，许多数据库实现使用区分大小写的名称，因此请始终使用创建时使用的大小写来引用表和列(由于您未指定特定的实现，所以我通常讲的很一般)。

对于MySQL，以下是一些有关如何处理标识符大小写的有趣信息。您可以设置一些选项来确定它们在内部的存储方式。 http://dev.mysql.com/doc/refman/5.0/en/identifier-case-sensitiveivity.html

据我所知，常见的L.A.M.P.设置并不重要-但是请注意，Linux上托管的MySQL区分大小写！

为了使我的代码整洁，我通常坚持使用表和列的小写名称，大写的MySQL代码和混合的大写-小写变量-像这样：

SELECT * FROM my_table WHERE id ='$ myNewID'

我将pascal大小写用于字段名，将小写用于表名(通常)，如下所示：

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％的典型关系结构。

我没有发现FirstName比first_name更可读。 就我个人而言，出于自动化或动态报告的需要，我总是使用下划线(类似于您提到的内容)。 您已经在下划线使用了Student_ID，所以我认为继续遵循相同的逻辑而不是混合使用(并使逻辑更加复杂)会更有意义。 例如，带有外键table_name2_id的table_name指向table_name2上的id。 这样更好，因为您不必担心" StudentID"中的缩写，例如" ID"。

SQL标准要求名称以大写形式存储

SQL标准要求标识符必须全部大写。请参阅此答案中有关另一个问题的副本草稿中引用的SQL-92的5.2.13节。该标准允许您使用小写或大小写混合的无限制标识符，因为需要SQL处理器根据需要进行转换以转换为大写版本。

该要求大概可以追溯到SQL的早期，当时大型机系统仅限于大写英文字符。

没问题

许多数据库标准都忽略了这一要求。尤其是Postgres正好相反，将所有未加引号("无限制")的标识符转换为小写字母-尽管Postgres否则比我所知道的任何其他系统都更接近标准。在您指定的情况下，某些数据库可能会存储标识符。

通常这是非问题。几乎所有数据库都会从标识符使用的大小写到数据库存储的大小写进行不区分大小写的查找。

有时候，您可能需要在存储的情况下指定标识符，或者可能需要指定全部大写的情况。在某些实用程序中可能会发生这种情况，在这些实用程序中，您必须在通常的SQL处理器上下文之外将标识符作为字符串传递。很少见，但是将其藏在脑后，以防有一天在使用某些不寻常的工具/实用程序时遇到一些神秘的"找不到表"错误消息。曾经发生在我身上。

蛇皮套

如今，常见的做法似乎是在所有小写字母之间加上下划线。这种样式被称为蛇皮套。

如果您的标识符曾经全部用大写(或全部小写)显示，则使用下划线而不是驼峰式大小写会有所帮助，从而在没有单词分隔的情况下失去可读性。

温馨提示：SQL标准(SQL-92第5.2.11节)明确承诺永远不要在关键字中使用结尾的下划线。因此，请在所有标识符后面加上下划线，以消除所有意外碰撞的烦恼。

无论使用什么，请记住Linux上的MySQL区分大小写，而Windows上的MySQL不区分大小写。

例如，如果使用的是postgresql和PHP，则必须这样编写查询：

$sql = "SELECT somecolumn FROM "MyMixedCaseTable" where somerow= '$somevar'";

"引用标识符也使其区分大小写，而未引用的名称总是折叠为小写。例如，PostgreSQL认为标识符FOO，foo和" foo"是相同的，但是" Foo"和" FOO"是两者之间是不同的。(在PostgreSQL中，将未加引号的名称折叠成小写是与SQL标准不兼容的，SQL标准说，未加引号的名称应该被折叠成大写。因此，foo应该等于" FOO"而不是" foo"。根据标准。如果您要编写可移植的应用程序，建议您始终使用特定名称，也不要使用任何特定名称。)

http://www.postgresql.org/docs/8.4/static/sql-syntax-lexical.html#SQL-SYNTAX-IDENTIFIERS

因此，有时候，这取决于您在做什么...

没有现代的数据库不能处理大写或小写文本。

@MarkyPython-那就是我在说什么：他们都可以处理它们。 没有人不能处理它们。