我想知道是否有问题,如果表或列名包含大写字母。有些东西让我相信当一切都保持小写时,数据库的麻烦会更少。真的吗?哪些数据库不喜欢表名和列名中的任何大写符号?
我需要知道,因为我的框架会从 ER 模型自动生成关系模型。
(这个问题不是关于它的风格是好是坏,而只是关于它是否是任何数据库的技术问题)
我想知道是否有问题,如果表或列名包含大写字母。有些东西让我相信当一切都保持小写时,数据库的麻烦会更少。真的吗?哪些数据库不喜欢表名和列名中的任何大写符号?
我需要知道,因为我的框架会从 ER 模型自动生成关系模型。
(这个问题不是关于它的风格是好是坏,而只是关于它是否是任何数据库的技术问题)
据我所知,使用大写和小写都没有问题。使用小写约定的原因之一是使用小写表和列名以及大写 sql 关键字的查询更具可读性:
SELECT column_a, column_b FROM table_name WHERE column_a = 'test'
对于我知道的任何数据库引擎,数据库在表名或列名中包含大写字母都不是技术问题。请记住,许多数据库实现使用区分大小写的名称,因此始终使用与创建它们相同的大小写来引用表和列(我说的非常笼统,因为您没有指定特定的实现)。
对于 MySQL,这里有一些关于它如何处理标识符大小写的有趣信息。您可以设置一些选项来确定它们在内部的存储方式。 http://dev.mysql.com/doc/refman/5.0/en/identifier-case-sensitive.html
SQL-92 标准规定标识符和关键字不区分大小写(根据SQL 标准第 4 版指南,日期/达尔文)
这并不是说特定的 DBMS 不是 (1) 损坏的,或者 (2) 可配置的(并且损坏的)
从编程风格的角度来看,我建议对关键字和标识符使用不同的大小写。就个人而言,我喜欢大写标识符和小写关键字,因为它突出显示了您正在操作的数据。
SQL 标准要求标识符以全大写形式存储。请参阅 SQL-92 的第 5.2.13 节,引用自此关于另一个问题的答案中的草稿副本。该标准允许您使用小写或混合大小写的未定界标识符,因为 SQL 处理器需要根据需要进行转换以转换为大写版本。
这个要求大概可以追溯到 SQL 的早期,当时大型机系统仅限于大写英文字符。
许多数据库忽略了这个标准的要求。
例如,Postgres 正好相反,将所有未加引号(“未定界”)的标识符转换为小写——尽管 Postgres 在其他方面比我所知道的任何其他系统都更接近标准。
某些数据库可能会在您指定的情况下存储标识符。
一般来说,这不是问题。几乎所有数据库都会从标识符使用的大小写到数据库存储的大小写进行不区分大小写的查找。
偶尔会有一些奇怪的情况,您可能需要在其存储的大小写中指定一个标识符,或者您可能需要指定全大写。这可能发生在某些实用程序中,您必须在通常的 SQL 处理器上下文之外将标识符作为字符串传递。很少见,但是把它藏在脑后,以防有一天你在使用一些不寻常的工具/实用程序时遇到一些神秘的“找不到表”类型的错误消息。曾经发生在我身上。
现在的普遍做法似乎是使用所有小写字母和下划线分隔单词。这种风格被称为蛇壳。
如果您的标识符曾经全部显示为大写(或全部小写)并因此在没有单词分隔的情况下失去可读性,则使用下划线而不是Camel 大小写会有所帮助。
额外提示:SQL 标准(SQL-92 第 5.2.11 节)明确承诺永远不会在关键字中使用尾随下划线。因此,在所有标识符后面附加一个下划线,以消除意外碰撞的所有担忧。
据我所知,对于常见的 LAMP 设置,这并不重要 - 但请注意,Linux 上托管的 MySQL 区分大小写!
为了保持我的代码整洁,我通常坚持使用小写的表和列名称,大写 MySQL-Code 和混合的大写小写变量 - 像这样:
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% 的典型关系结构。
无论您使用什么,请记住 Linux 上的 MySQL 是区分大小写的,而在 Windows 上是不区分大小写的。
没有现代数据库不能处理大写或小写文本。
例如,如果您使用的是 postgresql 和 PHP,则必须像这样编写查询:
$sql = "SELECT somecolumn FROM \"MyMixedCaseTable\" where somerow= '$somevar'";
“引用标识符也使其区分大小写,而未引用的名称总是折叠为小写。例如,标识符 FOO、foo 和“foo”被 PostgreSQL 认为是相同的,但“Foo”和“FOO”是与这三个不同。(在PostgreSQL中将不带引号的名称折叠为小写与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 标准的信息是否正确——如果是这样,这部分标准并没有被广泛遵循。)