有时，我们在 DB 中有很多字段和大型数据集（我使用的是 mongoDB）。我想到了一件事，就是通过在 DB 中保留缩短名称来在 DB 中保存一些字节。 喜欢
年份：年
月: mn
isSameCity : isSmCt
那么，这种方法是好是坏。或者，这取决于案例基础。
请在这方面指导我。
【问题讨论】：
标签： php python database mongodb
MongoDB 的一种常见性能优化策略是在文档中使用短字段名称。
也就是说，不是创建一个看起来像这样的文档...
{first_name: "Jon", last_name: "Hyman"}
使用较短的字段名称，以便文档看起来像...
{fn：“乔恩”，ln：“海曼”}
由于 MongoDB 没有列或预定义模式的概念，因此这种结构是有利的，因为字段名称在数据库中的每个文档上都是重复的。如果您有一百万个文档，每个文档上都有一个“first_name”字段，那么您将存储该字符串一百万次。这会导致每个文档有更多空间，这最终会影响到内存中可以容纳多少文档，并且在大规模情况下，可能会略微影响性能，因为 MongoDB 必须在读取文档时将文档映射到内存中。
【讨论】：
在设计数据模型时可以避免使用长命名属性（或“AbnormallyLongNameAttributes”）。在我之前的组织中，我们测试了保留简短命名属性的策略，例如，组织定义了 4-5 个字母编码的字符串，例如：
虽然我们观察到查询性能有所提高，但主要是由于通过网络传输的数据大小减少，或者（因为我们将 JAVA 与 MongoDB 一起使用）减少了 MongoDB 文档/Java Map 中“键”的长度堆空间，整体性能提升不到 15%。
在我个人看来，这是一个微优化，需要额外的成本（巨大的麻烦）来维护/设计一个额外的系统来管理每个数据模型的数据属性字典。该系统需要在调试应用程序/回答客户查询时具有组织范围内的透明度。
如果您发现使用此策略将性能提高 20% 对您来说是有利可图的，那么可能是时候扩展您的 MongoDB 服务器/选择其他一些数据建模/查询策略了，或者完全选择不同的数据库。
【讨论】：
引用Donald Knuth：
过早的优化是编程中万恶（或至少是大部分）的根源。
然而，构建您的应用程序似乎是最明智、可维护和合乎逻辑的。然后，如果您遇到性能或存储问题，请处理影响最大的问题，直到性能令人满意或收益递减规律意味着没有必要进一步优化。
如果您不确定特定设计决策的影响（例如长属性名称），请创建一个原型来测试各种假设（例如“较短的属性名称会节省很多空间”）。不要期望测试的结果是决定性的，但它可能会教给你你没想到会学到的东西。
【讨论】：