在Firebase中构建关系 [英] Structuring Relationships in Firebase

问题描述

我的Firebase中有两个项目： providers 和 services ，我试图使用Firebase推荐的扁平化架构方法构建和建立关系的最佳方式。

我的数据看起来像这样：

  {
services：{
hip_replacement：{
title：Hip Replacement
} 
 
 
providers：{
the_blue_hospital：{
title：The Blue Hospital
} 
} 
 
 
 
 
 
 $ b我想将这两个项目连接在一起，以便如果您要访问髋关节置换页面，蓝色医院将显示在它下面，如果您要访问蓝色医院页面，髋关节置换将显示在下面。双向关系，本质上。
 
 
 
什么是最好的方式来构建这样的东西？我在想：
 
 $ p code $ {
services：{
hip_replacement： {
title：Hip Replacement，
providers：{
the_blue_hospital：true，
the_red_hospital：true 
} 
 
 
 
providers：{
the_blue_hospital：{
title：蓝色医院，
 $，
the_red_hospital：{... 
}，
the_green_hospital：{... 
} 
} 
} 
  

有没有更好的方法来实现这个或更优雅的解决方案？任何帮助表示赞赏。

在此先感谢！

Firebase中加入数据的问题在于，您可以优化某些阅读或更新用例，而牺牲其他用例。在上面的示例中，创建或删除服务和提供者之间的关系需要对每个表进行两次单独更新。这真的没有什么问题，但它不是唯一的方法。

对于一个中等规模的数据集，你可以有一个连接表，将服务映射到提供者，类似于在关系数据库领域可能做的事情。数据可能如下所示：

  {
services：{
hip_replacement： {
}，
providers：{
the_blue_hospital：{...}，
the_red_hospital：{...}，
 the_green_hospital：{...} 
}，
serviceProviders：{
-JqD5JX0RUDTXsu7Ok3R：{
provider：the_blue_hospital，
服务：hip_replacement
} 
-JqDoKfyJqPkQlCXDvFM：{
provider：the_green_hospital，
service：hip_replacement
} 
-JbE7Ji_JRz2bHgBdMWQ：{
provider：the_blue_hospital，
service：hip_replacement
} 
} 
  
 $ b这种方法有利有弊：
 $ b 
  
 / b> 
 
 
 
 
在一个地方轻松添加映射
 
 
轻松删除一个地方的映射
 
 
灵活的选项可以重新格式化显示的数据，超出上下文一个提供商或服务，如索引。
 
 
 
 
 
  Con  
 
 
 
 
 
您已加载整个数据集。 Firebase不允许您在一个密钥内进行过滤，客户端必须加载整个列表，然后在内存中进行过滤。我怀疑这可以很好地处理数百条记录，反正也可能只有很少的记录。
 
 
你必须做一些客户端工作来过滤显示列表并将其与实际服务合并，提供者数据。再次，如果数据集不是太大，下划线/ lodash groupBy（）可以做这个简短的工作。
 
 
 
你应该考虑：
 
 
 
 
你会做多少次更新和删除？ 
 
 
连接信息真的很简单吗？你需要更多的记录（显示名称，价格等），使连接表上的维护比我建议的更复杂吗？
 
I've got two items in my Firebase: providers and services, and I'm trying to figure out the best way to structure and build relationships using Firebase's recommended flattened architecture approach.

My data looks something like this:
{
  "services" : {
    "hip_replacement" : {
      "title" : "Hip Replacement"
    }
  },

  "providers" : {
    "the_blue_hospital" : {
      "title" : "The Blue Hospital"
    }
  }
}
I would like to link these two items together so that if you were to visit the Hip Replacement page, The Blue Hospital would show up underneath it, if you were to visit The Blue Hospital page, Hip Replacement would show up underneath that. A two-way relationship, essentially.

What would be the best way to structure something like this? I was thinking along the following lines:
{
  "services": {
    "hip_replacement": {
      "title": "Hip Replacement",
      "providers": {
        "the_blue_hospital": true,
        "the_red_hospital": true
      }
    },
    ...
  },
  "providers": {
    "the_blue_hospital": {
      "title": "The Blue Hospital",
    },
    "the_red_hospital": {...
    },
    "the_green_hospital": {...
    }
  }
}
Is there a better way to achieve this or a more elegant solution? Any help is appreciated.

Thanks in advance!
解决方案
The problem with joined data in Firebase is that you optimize for certain read or update use cases at the expense of others.  In your sample above, creating or deleting a relationship between services and providers requires two separate updates to each "table".  There's really nothing wrong with that, but it's not the only way to go.

For a modestly sized data set, you could have a "join table" that maps services to providers, similar to what might be done in the relational DB world.  The data might look something like this:
{
  "services": {
    "hip_replacement": {}
  },
  "providers": {
    "the_blue_hospital": {...},
    "the_red_hospital": {...},
    "the_green_hospital": {...}
  },
  "serviceProviders": {
    "-JqD5JX0RUDTXsu7Ok3R": {
      "provider": "the_blue_hospital",
      "service": "hip_replacement"
  }
    "-JqDoKfyJqPkQlCXDvFM": {
      "provider": "the_green_hospital",
      "service": "hip_replacement"
  }
    "-JbE7Ji_JRz2bHgBdMWQ": {
      "provider": "the_blue_hospital",
      "service": "hip_replacement"
  }
}
There are pros and cons of this approach:

Pro


Easy to add mappings in one place
Easy to delete mappings in one place
Flexible options to reformat the data for display, beyond the context of a single provider or service, such as an index.


Con


You have load the whole data set.  Firebase doesn't let you filter within a key, clients have to load the whole list, then filter in memory.  I suspect this will work fine for hundreds of records, anyways, maybe for low thousands.
You have to do some client work to filter the list for display and merge it with the actual service and provider data.  Again, if the data set isn't too big, underscore/lodash groupBy() can make short work of this.


You should consider:


How much updating and deleting will you do? 
Is the join information really that simple?  Would you need more records (display names, prices, etc.) that make maintenance on the join table more complicated than I suggested?


                        
这篇关于在Firebase中构建关系的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！