MongoDB模式设计 - 巨大的列表

MongoDB schema design - huge list

本文关键字：巨大 列表 模式 MongoDB      更新时间：2023-09-26

我想知道在我的mongoDB中存储数据的最佳方式是什么，例如，餐厅的订单。

因此，首先我需要有一个"订单"集合。

还需要对服务员之间的数据同步进行大量读取，因此我不想存储已完成（已付款）的订单和仍在同一列表中打开的订单。

所以我想出了一个"订单"集合，它有 2 个数组字段："当前"和"历史"。目前，我将存储所有尚未付款的订单（需要通过所有服务员同步），而在"历史记录"中，我将存储所有已关闭且仅需要由经理或想要查看数据的人访问的内容。

这样，我可以最大限度地减少访问时间和发送数据量。

这是执行此操作的正确最佳实践方法吗？

或者我应该将所有内容存储在一个列表中，然后执行按时间或类似方式排序的查询，并限制我发回的文档数量？

编辑：

在此集合中，我希望保存多家餐厅的订单。 所以我可以为每个餐厅使用这个集合中的一个文档并将订单嵌入其中，或者把这个集合中的所有订单放在同一个级别上，然后每个订单都有一个restaurantId

由于订单集合代表单个餐厅，因此它不会包含所有订单的记录，每个文档如下所示：

{
    _id:{}
    waiter: 'Sammaye',
    table: 9,
    items: [
        {id:9,qty:1,cooked:false}
    ],
    billed: false
}

所有需要了解等待外出的订单的服务员都会从这个集合中获得所有billed false的订单文件。

如果您在 billed 上放置索引，这应该足够好。

使用您所说的另一种方法可能会导致问题，例如，它是存储所有订单的集合中的一个文档。我可以想象，随着时间的推移，这份文件可能会变得非常大。

在内存中使用运算符（$push、$pull等）会使文档的操作变慢。

它还可能在数据库中创建碎片，因为这些是随着时间的推移而不断增长的未绑定数组，这也会降低性能。

与将每个订单存储为记录相比，您的方法也不会产生任何优势，除了您可以一次性获取所有待处理订单，但是，配置批量大小，将所有订单存储为单独的文档时，您可能会非常接近。

相关文章：