如何在维护数据库模型的同时从 firestore 中删除文档？

Question

我读过这篇文章，如果您发现我的解释晦涩难懂，请参考它。基本上，其想法是为每个文档分配一个

last_modified

字段，每当您添加或编辑文档时，该字段都会根据访问或修改的日期进行更新。每当查询 firestore 数据库时，日期都会保存在用户设备上的

lastQueried

中。您在 firestore 数据库中查询

last_modified

>

lastQueried

的文档，并且应该仅返回已添加或修改的文档。查询结果存储在用户本地数据库中。

现在讨论手头的问题。假设您从 firestore 数据库中删除了一个文档。用户的本地数据库将无法检测到该删除，除非它读取整个 firestore 集合。

我想出的解决方案是在文档中添加

deleted

或更专业的

archived

布尔字段，这将允许我使用

archived: true

从本地数据库中删除任何文档。这不是一个最优的解决方案；但是，因为虽然它保持了“降低阅读成本”的主题，但是文档仍然会保留在数据库中，这对于需要大量删除的数据库来说并不是很好。

我不是数据库专家，但我认为这个数据库设计是一个标准。那么，你会如何解决这个问题呢？我的初始设计是否有缺陷或不适合我的用例？

任何帮助将不胜感激。

Answer 1

你会如何解决这个问题？

您实际上无法替代所提供的解决方案。为了实现此方案，您必须接受“删除”文档并将该事件传播到客户端的唯一方法，您必须使用字段来标识为“已删除”而不是实际删除它。

如果您不想永远接受数据库中的这些“逻辑删除”文档，那么您需要弄清楚何时实际删除它们，以及如何通知所有相关的客户端应用程序发生了这种情况。否则，客户端可能会变得不同步，认为存在文档，但实际上根本不存在。

我们无法告诉您删除这些逻辑删除文档的频率。这由您决定，基于您愿意接受多少成本和错误。

如果您选择删除逻辑删除文档，让客户端恢复与数据库同步的唯一 100% 准确的方法是让客户端定期查询整个集合并协调结果中任何丢失的文档。您必须接受这样的事实：在同步发生之前，客户端可能不知道某些最近删除的文档。至少，客户端需要一个不被删除的文档ID列表。

再次强调：这很大程度上完全取决于您愿意接受多少错误和成本，我们无法告诉您到底应该做什么。