Question

我昨天第一次听说Firebase。看起来对我很有希望。我已准备好几篇关于在Firebase中对数据进行反规范化的文章。我正在考虑从MySQL后端迁移到Firebase。这将在iOS应用中使用。

典型场景：

飓风发展
飓风中心每隔6小时就风暴发布一次建议
每个通报都包含未来职位（预测）..最多8个职位
每个位置都有一个位置（纬度/经度），风暴强度（风速）
每个位置还具有与该位置相关的风半径信息

具体问题：在我的结构中，我是否应该在公告下嵌套？任何其他提示/建议将不胜感激！

这是我对数据结构的第一次尝试：

{
storms: {
    id: "AL012015"
    name: "Alex"
    basin: "NWP"
}
advisories: {
    stormID: "AL012015"
    advisorynumber: "1"     //will have many advisories throughout the lifecycle of the storm
    date: "2015-06021 18:00:00"
    cat: "H1"
    eyediameter: "20"
    movedirection: "270"
    movespeed: "13"
    pressure: "999"
    fa: "full text advisory"
    pa: "full test public advisory"
    cd: "full text cyclone discussion"
    agency: "NHC"
}
positions: {            //can be up to 8 positions per advisory
    stormid: "AL012015"
    advisorynumber: "1"
    positions: {    
        position1: {
            datetime: "2015-07-21 18:00:00"
            speed: "75"
            lat: "23.5"
            lon: "-78.2"
            radius34ne: "120"  //radius of the 34 knot winds speeds from center
            radius34se: "145"
            radius34sw: "100"
            radius34nw: "120"
            radius50ne: "90"  //radius of the 50 knot winds speeds from center
            radius50se: "100"
            radius50sw: "75"
            radius50nw: "90"
            radius64ne: "60"  //radius of the 64 knot winds speeds from center
            radius64se: "75"
            radius64sw: "50"
            radius64nw: "60"
        }
        position2: {
            datetime: "2015-07-22 00:00:00"
            speed: "85"
            lat: "24.5"
            lon: "-75.2"
            radius34ne: "120"  //radius of the 34 knot winds speeds from center
            radius34se: "145"
            radius34sw: "100"
            radius34nw: "120"
            radius50ne: "90"  //radius of the 50 knot winds speeds from center
            radius50se: "100"
            radius50sw: "75"
            radius50nw: "90"
            radius64ne: "60"  //radius of the 64 knot winds speeds from center
            radius64se: "75"
            radius64sw: "50"
            radius64nw: "60"
        }
        position3: {
            datetime: "2015-07-22 06:00:00"
            speed: "60"
            lat: "26.5"
            lon: "-72.2"
            radius34ne: "50"  //radius of the 34 knot winds speeds from center
            radius34se: "55"
            radius34sw: "50"
            radius34nw: "45"
            radius50ne: "20"  //radius of the 50 knot winds speeds from center
            radius50se: "20"
            radius50sw: "20"
            radius50nw: "20"
            //no 64 knot wind radius because "speed" < 64
        }
    }
}

}

Answer 1

Firebase更喜欢扁平化的数据结构，因此不要在公告中嵌套。

此外，如果您计划保留每次风暴的记录，您可能希望嵌套每个风暴的属性，例如＆＃34; id＆＃34;和＆＃34;盆地＆＃34;在暴风雨的名下＆＃34; （或者如果名称可能有重复，您可以使用ID）。每个建议和职位也是如此。

Firebase的网站还提供了一个很好的指南，可以将最佳实践数据结构与其后端服务配合使用：https://www.firebase.com/docs/web/guide/structuring-data.html

Answer 2

朱利安的回答是正确的，我想补充一些内容并提供一个例子。

通过以下内容，我们有三个主要的父节点，风暴，建议和职位。

每个中的父节点都是Firebase自动生成的ID。将子数据节点与父节点名称解除关联是件好事。

在暴风雨，建议和位置节点中，每个孩子都有一个由autoId生成的名称（push（））。在顾问和职位节点中，有一个孩子引用风暴节点。

storms:
  storm_id_0:
    id: "AL012015"
    name: "Alex"
    basin: "NWP"
  storm_id_1:
    id: "BI01923"
    name: "Biff"
    basin: "NWP"

advisories:
   advisory_id_0:
     stormID: storm_id_0
     advisorynumber: "1"
     date: "2015-10021 18:00:00"
     eyediameter: "20"
     text: "The eye wall is building"
   advisory_id_1:
     stormID: storm_id_0
     advisorynumber: "2"
     date: "2015-10021 18:00:00"
     eyediameter: "25"
     text: "The storm has deep convection"

positions:
  position_id_0
    stormID: storm_id_0
    datetime: "2015-07-21 18:00:00"
    speed: "75"
    lat: "23.5"
    lon: "-78.2"
    radius34ne: "120"
  position_id_1
    stormID: storm_id_0
    datetime: "2015-07-21 18:00:00"
    speed: "75"
    lat: "23.5"
    lon: "-78.2"
    radius34ne: "120"
  position_id_2
    stormid: storm_id_0
    datetime: "2015-07-21 18:00:00"
    speed: "75"
    lat: "23.5"
    lon: "-78.2"
    radius34ne: "120"

您可以查询一些有趣的事情。

例如：您可以查询（或观察事件）所有关于storm_id_0，storm_id_1等的建议。不是很令人兴奋，但会获得每次风暴的基础数据。

您可以查询横跨纬度23.5的所有风暴。更令人兴奋的

甚至可以查询眼睛直径在20到25之间的所有风暴。非常令人兴奋。

如果数据嵌套太深，您仍然可以获得相同的信息，但它需要在客户端进行更多的工作。

希望这有帮助。

Firebase数据结构 - 我是否走在正确的轨道上？

2 个答案: