0

我看到人们使用 date 或 getTime 存储/获取服务器时间和相对于它的时间，它们可以作为字符串保存在数据库中：“July 21, 1983 01:15:00”。

到目前为止，我将服务器时间存储为 NOW 和 2013 年 1 月 1 日之间的差值。这将返回一个数值（以分钟为单位），在 2013 年 1 月 1 日和现在之间四舍五入，我将其保留为内部服务器时间。

这样做的好处是： - 查询服务器意味着一个简单的数字比较操作，而（我做出有根据的猜测）比较两个日期意味着内部转换为对象并使用胖比较操作。- 存储该大小的数字比约 25 个字符的字符串更轻量。- 转换回“实时”时间是通过添加 2013 年 1 月 1 日，但由于初始圆度，秒和毫秒值会丢失。

但是，其他程序员仍然坚持认为使用字符串版本 - 作为人类很容易阅读。- 它是大多数语言的通用格式（尤其是本项目拥有的 nodejs、mongodb 和 as3）。

我不确定哪个更适合大型数据库，特别是基于多人套接字的游戏。我相信在这方面有实际经验的其他人可以对我的问题有所了解。

那么哪个更好，为什么？

4

1 回答 1

1

将它们存储为 Mongo Date 对象。Mongo 将日期存储为 8 字节秒偏移整数 [1]，并以人类可读的格式显示它们。您没有存储 25 个字符！

因此，所有比较都一样快。除了查询时，没有字符串解析，这是每次查询的一次性操作。

您的差异存储为 4 个字节的 int。因此，与普通的 MongoDB 日期存储相比，您只节省了 4 个字节。考虑到 mongo 对象的平均大小，这是一个非常小的节省。

考虑“自 2013 年 1 月以来的抵消”方法的所有缺点：

  • 在更新或查询时花费时间编写额外的逻辑来抵消日期。
  • 处理因忘记偏移日期而产生的错误所花费的时间。
  • 在检查数据库输出（诊断问题时）时手动或在脑海中移动日期所花费的时间，而不是立即查看实际日期。
  • 在没有额外工作的情况下无法在 MongoDB 聚合中使用日期运算符（例如，$dayOfMonth，额外的工作是将您的日期在内部转移到的投影）。

基本上，更多的代码，更多的头痛和更多的时间花费，所有这些都是为了在数据库中的对象上保存 4 个字节，通过将字段从“更新”重命名为“更新”可以保存相同的 4 个字节？我不认为这是一个明智的权衡。

此外， 在 mongodb 中存储日期/时间的最佳方式

过早的优化是万恶之源。除非您确定某些问题存在，否则不要优化。

1 - http://bsonspec.org/#/specification

于 2013-08-22T13:16:06.740 回答