8

当我开始进行数据库设计时，出于某种原因，建议您始终对表和列使用蛇形大小写 (my_table_name)。我认为这在 MySQL 中尤其如此。原因是在某些情况下会丢失或强制使用大写字母。快进到今天，我看到很多人使用我更喜欢的 Pascal Case ("MyTableName")。

是否有任何理由仍然对表名和列名使用蛇形大小写？是否存在大小写可能丢失或强制执行的情况（例如，如果更改数据库引擎、操作系统等）？

4

3 回答 3

10

SQL 不区分大小写。许多数据库在创建表时会将名称折叠为小写，因此会丢失大小写。

在名称中保留“单词”的唯一可移植方法是使用蛇形大小写。

于 2013-04-29T21:37:50.023 回答
3

来自http://dev.mysql.com/doc/refman/5.0/en/identifier-case-sensitive.html：

“在 MySQL 中，数据库对应于数据目录中的目录。数据库中的每个表对应于数据库目录中的至少一个文件（可能更多，取决于存储引擎）。因此，底层操作系统的大小写敏感性在数据库和表名的大小写敏感中起作用。这意味着数据库和表名在 Windows 中不区分大小写，而在大多数 Unix 版本中都区分大小写。一个值得注意的例外是 Mac OS X，它基于 Unix，但使用不区分大小写的默认文件系统类型 (HFS+)。”

简而言之，它取决于数据库下的文件系统。

如今，大多数 mysql 服务器运行在具有 ext3/ext4/bttrfs/namesomeother 文件系统的 linux 系统上，这些文件系统区分大小写。例如 FAT12 不区分大小写，甚至不保留大小写，因此创建后 mysql 可能找不到数据库 MyDB。Fat32 和 HFS+ 不区分大小写，但会保留大小写；所以你可能会在使用 Mydb 和 myDB 时遇到麻烦。

因此，如果您知道您的数据库可能托管在 FAT12 系统上，您可能仍需要确保您注意案例。

于 2013-04-29T21:45:34.123 回答
0

SQL 不区分大小写，除非您使用分隔标识符。上面的示例将普通标识符与定界标识符进行了比较。使用分隔标识符时，标识符规则消失了；这是一个有效的标识符“4argo @##$@ 你自己”。

串在一起的单词比分开的单词更难阅读，而且更容易出现拼写错误，尤其是有时涉及复数时。

分隔标识符允许您模仿区分大小写的应用程序语言，但它们可能会导致元数据搜索等问题。您可以轻松地以特定于供应商的行为结束，这显然是一个痛苦。

一些 DBMS 是在 SQL 标准化为折叠为大写之前实现的；他们永远不会改变。（我的猜测是 IBM 在某个会议上赢得了一场争论，并将其改为大写。）而且，只要正确处理不区分大小写，他们就不必这样做。

根据您使用的特定 DBMS 的实现方式来建模您的模式是一个坏主意。

于 2021-04-29T20:54:10.310 回答