大佬教程收集整理的这篇文章主要介绍了Firebase-Firestore 结构化，大佬教程大佬觉得挺不错的，现在分享给大家，也给大家做个参考。
想象一下，我有多家公司，每家公司都有多名员工、多辆车辆、多条路线、出发地、捕获的损坏和任务（谁必须开车旅行）。
我应该如何构建我的 Firestore 以使其简单且具有概览性？当前的结构看起来有点像这样：
我有多个收藏，其中包含所有不同的公司、所有车辆、所有员工等等...
- employees:
- employyedocuments
- fIEld with CompanyId (reference to the company document)
- fIEld with employeEID (the uID of that employee,used for IDentification)
- companIEs:
- companydocuments
- array of all the vehicles (each element is a reference to a vehicle in the vehicle collection)
- assignments:
- assignmentdocuments
- fIEld with employeEID
- fIEld with CompanyId
- fIEld with vehiclEID
- fIEld with routEID (all IDs are document references to the according documents)
- routes:
- routedocuments
- information about the route,waypoints,delivery options... (but NO CompanyId or employeEID,since that route should be reused and is assigned to an employee in assignments)
- damages:
- damagedocuments
- any recorded damages
集合和文档比较多，但是都遵循类似的规则，这里就不用赘述了。我现在的问题是：有没有更好的方法来构造它以使其更易于阅读并避免意外混淆公司或员工？或者我使用的方法是正确的吗？我为丢失概览或数据库变得一团糟而感到难过。
教育会很棒！
总的来说，您的结构看起来不错，但这可能是“多对多”的情况，可以通过多种方式解决。根据经验，保持简单但模块化一直是关键。
使用文档名称作为该实体的 UID 保留文档是一种常见的久经考验的解决方案。 简单地引用一个 id 作为字段属性，一个公司员工的 id 数组等。
您还应该通过将所有当前员工文档合并到雇主或 HR 的主文档中来管理主员工文档，并通过查询可能不在列表中的任何新员工来简单地更新它。
这种宁静的方法有助于减少维护需求并提高整体性能。
以上是大佬教程为你收集整理的Firebase-Firestore 结构化全部内容，希望文章能够帮你解决Firebase-Firestore 结构化所遇到的程序开发问题。
如果觉得大佬教程网站内容还不错，欢迎将大佬教程推荐给程序员好友。
本图文内容来源于网友网络收集整理提供，作为学习参考使用，版权属于原作者。
如您有任何意见或建议可联系处理。小编QQ：384754419，请注明来意。