MongoDB 的命名约定是什么？

保持简短：优化小对象的存储，SERVER-863。愚蠢但真实。我想几乎适用于关系数据库的规则也应该适用于此。并且经过这么多年，对于 RDBMS 表应该命名为单数还是复数，仍然没有达成一致意见...... MongoDB 说 JavaScript，所以使用 camelCase 的 JS 命名约定。 MongoDB官方文档提到你可以使用下划线，内置标识符也被命名为_id（但这可能是为了表明_id是私有的，内部的，从不显示或编辑。

---

数据库

骆驼香烟盒

在名称末尾附加 DB

使单数（集合是复数）

MongoDB 举了一个很好的例子：

要选择要使用的数据库，请在 mongo shell 中发出 use 语句，如下例所示： use myDB use myNewDB

内容来自：https://docs.mongodb.com/manual/core/databases-and-collections/#databases

收藏品

小写名称：避免区分大小写问题，MongoDB 集合名称区分大小写。复数：更明显地将某物的集合标记为复数，例如“文件”而不是“文件” >无单词分隔符：避免不同的人（错误地）分隔单词（用户名 <-> 用户名、名字 <-> 名字）的问题）。根据这里的一些人的说法，这是一个有争议的问题，但前提是该论点与集合名称无关，我认为不应该这样做；）如果您发现自己通过添加下划线或骆驼来提高集合名称的可读性您的集合名称可能太长或应酌情使用句点，这是集合分类的标准。更详细集合的点表示法：给出集合如何相关的一些指示。例如，如果您删除了“users”，您可以合理地确定您可以删除“users.pagevisits”，前提是设计架构的人做得很好。内容来自：https://web.archive.org/web/20190313012313/http://www.tutespace.com/2016/03/schema-design-and-naming-conventions-in.html

对于集合，我会遵循这些建议的模式，直到找到官方的 MongoDB 文档。

---

即使没有为此指定约定，对于一对一的关系，manual references 也始终以 Mongo 文档中引用的集合命名。名称始终遵循结构 <document>_id。

例如，在 dogs 集合中，文档将手动引用外部文档，其名称如下：

{
  name: 'fido',
  owner_id: '5358e4249611f4a65e3068ab',
  race_id: '5358ee549611f4a65e3068ac',
  colour: 'yellow'
  ...
}

这遵循为每个文档命名 _id 标识符的 Mongo 约定。

---

集合的命名约定

为了命名一个集合，需要采取一些预防措施：

具有空字符串 (“”) 的集合不是有效的集合名称。集合名称不应包含空字符，因为它定义了集合名称的结尾。集合名称不应以前缀“system”开头。因为这是为内部收藏保留的。集合名称中最好不要包含字符“$”，因为数据库可用的各种驱动程序不支持集合名称中的“$”。

创建数据库名称时要记住的事情是：

具有空字符串 (“”) 的数据库不是有效的数据库名称。数据库名称不能超过 64 个字节。数据库名称区分大小写，即使在不区分大小写的文件系统上也是如此。因此，最好将名称保持为小写。数据库名称不能包含以下任何字符“/, , ., “, *, <, >, :, |, ?, $,”。它也不能包含单个空格或空字符。

了解更多信息。请检查以下链接：http://www.tutorial-points.com/2016/03/schema-design-and-naming-conventions-in.html

---

我认为这都是个人喜好。我的偏好来自在 .NET 中使用 NHibernate 和 SQL Server，因此它们可能与其他人使用的不同。

数据库：正在使用的应用程序.. 例如：Stackoverflow

集合：名称单数，它将是什么集合，例如：问题

文档字段，例如：MemberFirstName

老实说，这并不重要，只要它与项目保持一致即可。开始工作，不要担心细节：P

---

在我们得到 SERVER-863 之前，建议您尽可能缩短字段名称，尤其是在您有大量记录的情况下。

根据您的用例，字段名称可能会对存储产生巨大影响。无法理解为什么这不是 MongoDb 的优先级，因为这将对所有用户产生积极影响。如果不出意外，我们可以开始使用我们的字段名称更具描述性，而无需考虑带宽和存储成本。

请执行vote。

---