还有什么理由仍然使用数据库表和列的蛇案例？

Question

回到我开始使用数据库设计时,出于某种原因,建议您始终对表格和列使用snake case(my_table_name).我认为在MySQL中尤其如此.理由是存在资本化将丢失或执行的情况.快进到今天,我看到很多人使用Pascal Case("MyTableName"),我更喜欢.

有没有理由继续使用蛇形表格和列名？是否存在可能丢失或强制执行大写的情况(例如,如果更改数据库引擎,操作系统等)？

Answer 1

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

在名称中保留"单词"的唯一可移植方法是使用蛇形案例.

Answer 2

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

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

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

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

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