我的数据库遵循以下命名约定。
由于我更喜欢对表和列使用描述性名称，因此我经常发现自己对具有两个或多个单词且未定义任何关系的实体使用 camelCasing。例如。
lastVisitIp
lastVisitDate
registrationDate
坦率地说，我不太喜欢使用 camelCasing 的想法，因为我觉得这样做有点难看，我不知道为什么。
我想从专家那里知道在这种情况下您对列命名有何看法？我应该继续使用驼色外壳，我应该使用Underscore(_) 还是任何其他替代品。？
P.S : 我检查了 Wordpress 中使用的命名约定，他们使用(_) Underscore 进行多用途。 :)
谢谢。
【问题讨论】：
标签： php database-design naming-conventions
我发现复数有时会使事情变得复杂，因为在 Users 表的情况下复数可以是“s”，在表名是 Companies 的情况下可以是“ies”。所以最好一直坚持使用单数。同样在 sql 加入语句时，我倾向于对 Users.user_id = Companies.owner_id 犯错误，但对 User.user_id = Company.owner_id 不会犯错误，因为您必须始终小心使用 's' 和 'ies'。
下划线是首选方式，因为列名可以由多个单词组成
is_user_registered_last_year VS isUserRegisteredLastYear
你可以看到更多的字母 骆驼案更难读。
【讨论】：
感谢这是一篇旧帖子，但我想加两分钱。
如果可能，数据库表应命名为复数形式，但尽量保持对它们的某种敏感性，以便名称能够指示内容，以便于识别。
以以下为例。
您的应用程序中有用户，您的模型将是 User，因为它指的是单个用户，数据库表将是 users，因为它是单个用户的集合。现在假设您有这些用户的个人资料，命名时有几个选项，但我觉得很合适。
users_profiles，但在阅读时，这可能意味着一对多关系，因为它是用户个人资料。user_profile，这确实表明它是一对一的关系，但另一方面，它确实暗示此表不是一个集合，而是一个单独的配置文件单个用户。user_profiles，因为它是用户配置文件的集合，即一个配置文件与一个用户相关。在此个人资料表中，您需要引用原始用户，因此您会有一个名为 user_id 的列，而不是 users_id，而是 user_id。至于任何其他列名，您应该尽量将其保留为一个单词，全部小写。如果您无法使用单个单词命名此列，请将其视为变量并使用下划线命名。这是有益的，因为在您有多个第一个单词相同的列的情况下，它会创建一种子集合，暗示它们是相关的，这是正确的。
确实，下划线暗示了一种关系，这就是为什么表被称为user_profiles，而字段被称为user_id，但是10次中有9次，你不会在一个字段上建立关系不是 id，所以暗示的问题就消失了。
上面提到总是使用单数作为复数可能会造成混淆。争论是复数可以以s 或ies 结尾。值得注意的是ies 实际上以s 结尾，所以这个问题用词不当。最重要的是，将表名保持为单数实际上会造成更多混乱，因为它并不立即暗示集合，而且确实意味着表名可以以几乎任何其他字母结尾。
有些表的名称会暗示复数，而不以s 结尾。例如，这可能类似于user_history。此表名是一个完全可以接受且易于识别的名称，因为 history 默认为复数形式，并且此表包含用户的历史记录。
不要做的事
正如您从这里的所有回复中看到的那样，有许多不同的选择，有的有优点，有的没有。这种特殊的方法是我虔诚地遵循的一种方法，据我所知，它是 PHP 中最常用的方法。它使事情保持整洁、易于理解，而且我很少（如果有的话）看到表名并且不知道它的作用。
希望对某人有所帮助。
【讨论】：
保持一致
如果您要使用前缀，请在任何地方使用它。如果您要拥有另一个表的外键，请在任何地方使用相同的列名。如果您要使用下划线分隔单词，请在任何地方这样做。
如何构建命名约定取决于您自己，只要保持其逻辑性，这样当您在几个月后回来时就知道该表的作用。
我自己，我使用下划线，我在任何地方都这样做，所以一切都有意义。
【讨论】：
对于我即将开始的一个新的大型项目，我昨天的想法完全相同，但我得出了相同的结论：使用_ 定义关系和 FK，其他所有内容都是驼峰式。一个例子：
party
partyPerson
partyOrganization
partyPerson_partyOrganization (how a person relates to an organization)
partyOrganizationLegal
party_address
party_contactMechanism
address
contactMechanism
如果您在所有内容下划线，将更难区分哪些是参考，哪些不是。
我还认为您应该在任何地方使用单数名称（这样更合乎逻辑，不太可能让您感到困惑）。
【讨论】：
你没有提到正在使用的 SQL 软件，但既然你提到了 WordPress，我猜这主要适用于 MySQL。
我会补充其他人所说的，并建议表名全部小写，而不是 camelCase。
虽然可以使用大写字符，但在将数据库环境从 UNIX-y 更改为 Windows，或者更具体地说，将区分大小写的操作系统更改为不区分大小写的操作系统时，您可能会遇到难以追踪的问题。
我通常在将内容从远程数据库推送或拉取到 Windows 中的本地开发机器时遇到这种情况。
有关这方面的更多信息，请参阅 MySQL 手册：
为避免此类差异引起的问题，最好采用 一致的约定，例如总是创建和引用 使用小写名称的数据库和表。这个约定是 推荐用于最大的便携性和易用性。
-- https://dev.mysql.com/doc/refman/5.7/en/identifier-case-sensitivity.html
【讨论】：