Firebase db架构

我的应用有工作和用户。当用户申请工作时，他们成为申请人。Firebase db架构

相关工作申请数据：resume (string), date (string), jobID (string), userID (string), coverLetter (string), fit(integer), rejected (boolean)

我想成为非规范化的数据通过无用数据的负载，以避免索引。所以，我计划：

job1: { 
applicants: { darnell: true} 

darnell: { 
    appliedTo: { job1: true }

我在哪里保留实际应用程序 - 在工作或用户？或者（我不想）称为“应用程序”的第三个模型？如何最好地组织这个模型？

2015-06-30 compguy24

应用程序与作业和用户之间的关系是什么？你还没有描述过这些如何融合在一起。你为什么说你不想要第三个模型？ – Kato

每个工作都有很多应用程序。每个应用程序都有一封特定于工作的求职信。每个应用程序都是针对单个用户的。我认为我不应该有第三种模式，因为我必须在三个地方更新数据库，但是我想我不确定真正的缺点在哪里。我目前已经决定把它全部保存在用户对象中，并由JobID进行索引，并在每个 – compguy24

上附上日期和求职信。由于用户可能存在于多个作业中，并且该应用程序特定于作业，因此它可能会使保持工作更有意义。当然，如果你想加载作业的元数据而不必加载所有的应用程序，那可能是错误的方法。了解数据读取方式的限制对于正确构造NoSQL应用程序至关重要。 – Kato

火力地堡是不是最大的，在关系数据库（它没有像.populate什么）。

所以，我想说的很大程度上取决于您如何查询数据，以及您是否想要长期使用Firebase（或最终会切换到Mongo等）。如果您从工作和申请方都查询申请（例如：给我所有与此工作相关的应用程序 - 并且 - 给我所有与此人相关的应用程序），那么我将为应用程序创建一个新模型。

如果没有，只需将它嵌入到有意义的父代（通常您想避免这种情况 - 但由于Firebase缺乏良好的查询，这可能是值得的）。

只是有些想法。

2015-07-01 02:46:05

回答