当我开始使用数据库设计时，出于某种原因，建议您始终对表格和列使用snake case（my_table_name）。我认为在MySQL中尤其如此。理由是存在资本化将丢失或执行的情况。快进到今天，我看到很多人使用Pascal Case（“MyTableName”），我更喜欢。
有没有理由继续使用蛇形表格和列名？是否存在可能丢失或强制执行大写的情况（例如，如果更改数据库引擎，操作系统等）？
答案 0 :(得分：6)
SQL不区分大小写。许多数据库在创建表时将名称折叠为小写，因此大写失去了。
在名称中保留“单词”的唯一可移植方法是使用snake case。
答案 1 :(得分：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不区分大小写，甚至不保留大小写，因此创建后mysql可能无法找到数据库MyDB。 Fat32和HFS +不区分大小写，但它保留了大小写;所以你可能会遇到Mydb和myDB的麻烦。
因此，如果您知道您的数据库可能托管在FAT12系统上，您可能仍希望确保观看案例。
答案 2 :(得分：0)
SQL 不区分大小写，除非您使用分隔标识符。上面的示例将普通标识符与分隔标识符进行比较。使用分隔标识符时，标识符规则消失；这是一个有效的标识符“4argo @##$@你自己”。
串在一起的单词比分开的单词更难阅读，而且更容易出现拼写错误，尤其是有时涉及复数时。
分隔标识符允许您模仿区分大小写的应用程序语言，但它们可能会导致元数据搜索等问题。您很容易以特定于供应商的行为告终，这显然是一种痛苦。
有些DBMS是在SQL被标准化折叠成大写之前实现的；他们永远不会改变。 （我的猜测是 IBM 在某个会议上赢得了一场争论并将其设为大写。）而且，只要正确处理不区分大小写的问题，他们就不必这样做。
根据您使用的特定 DBMS 的实现方式对架构建模是一个坏主意。