如何为餐厅提供存储数据架构

Question

我们有一个用于餐馆的订单跟踪应用程序，我们使用的是消防站。

我们有一些关于数据库体系结构的问题。我们应该如何保存这些数据？

我们目前按以下方式存储订单

服务器/{餐厅}/订单/ {OrderID}

每个订单文档都包含tableName参数，在接收表的订单和支付表的费用时，我们使用tableName字段查询该参数。

这应该是正确的架构吗？

服务器/{餐馆}/表/ {TableID} / orders / {OrderID}

服务器/{餐馆}/表/ {TableID} / payments / {paymentıd}

这是你能想象到的标准餐厅系统。

餐厅有很多表格，在这个表中有订单和付款，这就是它的工作方式.

Answer 1

这是一个高度固执己见和具体应用的问题。

使用Firestore / NoSQL，我建议首先从用户的角度对应用程序进行原型化。每个屏幕上的不同屏幕和相关数据是什么？这将帮助您识别经常执行的不同查询和读/写操作，以及如何最好地构造您的防火墙。

例如:您可能将表订单保存在单独的唯一文档中，但其中一个屏幕包含“订单摘要”，用户可以在其中查看前100个订单。此要求可能要求您还希望包含包含先前订单的摘要文档，以便当用户查看您的摘要屏幕时，您不会被收取100次读取操作的费用，而只是1次。

• 首先对视图进行原型化，
• 标识每个视图的数据模型
• 标识执行
• 所需的查询开始将满足上述需求的数据库基础结构组合起来(

)