【发布时间】：2017-02-04 09:46:25
【问题描述】：
案例：
我正在开发一个 POS 系统，我需要存储每个收银机终端的每笔交易（产品信息、价格、数量等）。这当然意味着交易文件的数量会随着时间的推移而增长。
我目前的解决方案如下：
有两个集合称为“注册”和“销售”。销售文件有一个注册 ID 参考，所以我知道哪些销售文件属于哪个收银机。交易存储在每个销售文档内的一个数组中（每天大约有 300 个新的交易文档）。
为了在更新已经很大的数组时获得更好的性能，我在每个销售文档和缓存数组已满时设计了一个小的“缓存”数组（大约 50 个文档 - 所以我大部分时间只更新小数组） ，我会将它们移动到主事务数组。
由于 MongoDB 中文档的最大大小限制为 16MB，因此我为销售文档设置了 10000 个事务的计数限制，如果事务数超过计数限制，我将创建一个新的销售文档并拥有他们的 id 引用存储在寄存器文档中的数组中，以保存销售文档的顺序。
我对这种设计不太满意，因为我必须编写非常复杂的查询来为每个查询检索大约 200 个事务，以使事务保持按顺序进行分页，并处理极端情况。
考虑：
所以我正在考虑制作一个非常大（不断增长）的集合，称为“交易”，我会将每个收银机的所有交易都扔到一堆，然后每笔交易都有自己的注册 ID 参考.
问题：我应该这样做吗？
更新： 我需要如何访问数据：
- 插入并只读，绝不更新或删除现有文档
- 插入是最频繁的操作
- 读取查询应返回适合事务编号范围或创建时间范围的文档数组，该数组不需要排序）
- 阅读：大多数时候，我只需要显示最近的前 200 笔交易。然后用户可以根据需要查询更多信息。
优点：
- 简单查询（但不确定是否有效），例如在查询特定数量的交易时，按 id 查找交易并按交易编号/时间范围过滤
- 避免不必要的重复
- 离无数组数据库更近一步
- 适合分片 (?)
缺点：
- 索引过多（这被认为是一个问题吗？如果这些小文档有数万亿个索引是否重要？）
- 我不知道我这样做之后会发生什么。从理论上讲，它应该工作。但现实比我们想象的更残酷
备注：
- 也许我选择数组而不是一堆集合的主要原因是我刚开始时没有任何 MongoDB 经验。
- 是的，我想确保交易井然有序
一些视觉效果：
【问题讨论】：
-
在 MongoDB 中，您应该根据访问数据的方式保存数据，我认为您还需要提及如何访问数据，就像您使用任何字段搜索一样，您将数据显示在根据哪些标准，您是否需要经常更新或删除任何数据？然后我们可以建议哪种方式更适合您。