如何在Firestore中为NoSQL数据结构建模（请参阅我的第一种方法）

Question

我是一位相当新的Web开发人员，在我目前正在从事的项目中需要您的帮助。过去，我曾研究过一个非常简单的实时数据库示例，并且对Firestore或NoSql几乎没有经验。

我想创建一个系统，该系统允许最终用户每周收到一封电子邮件，其中包含最终用户所订购酒吧的特别优惠列表。优惠在每周的每一天都会更改。酒吧老板可以每周在vue.js Web应用程序中填写其每周特惠信息。

每个星期一的cron工作都必须查找哪个最终用户已订阅了哪些酒吧，然后汇总数据并通过电子邮件发送。

问题是，您将如何构造数据，以便我可以轻松编写电子邮件并通过云功能发送电子邮件？

我的方法是拥有三个主要集合：RestaurantOwner，EndUser，SpecialOfferings

请参见图形以了解示例过程：

BarOwner和EndUser非常简单。但是，困难的部分是如何构造SpecialOffers以便以正确的方式进行查询。

我的想法是根据日历周构建它，并将其从barOwner链接到uid：

specialOffers: {
    2019_CW27: {
        barUID001: {
            mon: {
                title: 'Banana Daiquir',
                price: 4.99,
            },
            tue: {
                title: 'After Five',
                price: 2.99,
            },
            wed: {
                title: 'Cool Colada',
                price: 6.99
            },
            thu: {
                title: 'Crantini',
                price: 5.99
            },
            fri: {
                title: 'French Martini',
                price: 4.99
            }
        },
        barUID002: {
            mon: {
                title: 'Gin & Tonic',
                price: 8.99,
            },
            tue: {
                title: 'Cratini',
                price: 4.99,
            },
            wed: {
                title: 'French Martini',
                price: 4.99
            },
            thu: {
                title: 'After Five',
                price: 3.99
            },
            fri: {
                title: 'Cool Colada',
                price: 6.99
            }
        }
    },
    2019_CW28: { 
        barUID01: {~~~},
        barUID02: {~~~}
    }    
} 

这种方法的缺点是，当您想象有52个日历周，fe 100个注册酒吧和每周5个特价商品时，它会创建一个深层嵌套的对象，并且不确定是否可以查询该对象。我需要的方式。

这种方法合理吗？或者您会采取什么其他措施？

非常感谢您的帮助！非常感谢。

Answer 1

我假设以下情况：

1）酒吧老板经常对其报价进行修改。

2）酒吧所有者应该是唯一允许修改每个酒吧的要约的人。

如果您有这两种情况，建议在这里使用子集合方法。

何时使用子集合：

1）当文档中有很多字段时。 Cloud Firestore有20,000个字段限制。 （如果Bars的数量可以超过20,000个字段）

2）更新父集合时是常见的操作。 Firestore仅允许您以1个写入/秒的速度更新文档。 （如果每个小节的SpecialOffers信息被频繁修改。如果两个小节所有者修改其报价，则仅一次写入成功，第二次写入操作将等到第一个写入完成。这会延迟更新报价，尤其是在一周结束时，几乎所有酒吧都更新了报价。

3）当您想限制对文档特定字段的访问时。 （如果您只想限制对barOwner的酒吧要约的访问。您可以根据所有者使用Firestore Security Rules来限制对Bars子集合中每个文档的访问）

因此，我建议在主集合Bars下创建一个子集合SpecialOffers。这样，设计就变得可扩展，您可以在将来不加重大改动设计的情况下，将餐厅和超级市场添加为其他类似的子集合。

另一个优点是子集合基本上是集合，并且它们可以容纳的文档数量没有限制。因此，即使注册的条形数量超过20,000（这是消防文件的字段数的限制），您的子集合也不会出现问题，但是您的文件将用完字段以保存新报价酒吧。

最终选择取决于您的用例。

希望这会有所帮助。