Backendless 中的双向关系——处理高度相关的数据答案

【问题标题】：Bi-Directional Relationships in Backendless - Working with highly interrelated dataBackendless 中的双向关系——处理高度相关的数据
【发布时间】：2016-06-02 17:42:47
【问题描述】：

这是一个基本的新手级别的问题，不会很短。这是 Backendless 特有的。

我有许多我希望能够解决的场景，因为我正在处理一小组表，这些表都以某种形式相互关联，需要从各个方向进行探索。

一个基本的例子是 PersonTable 和 AddressTable。 PersonTable 包含人员列表，包括他们的姓、名等。AddressTable 包含地址及其各种属性，如 streetName、houseNumber 等。

假设我想在主导航中为用户提供两个不同的视图，并允许他们进一步下钻。

View1：单击“人员”，您会从 PersonTable 中获取人员列表。此列表显示在辅助导航窗口中。单击某个人将为您提供与该人关联的地址。

但是，我也希望能够反向执行此操作：

View2：单击“地址”，您会从地址表中获得地址列表。此列表显示在辅助导航窗口中。单击单个地址将为您提供与该地址关联的一个/多个人。

因此，从单向方法来看，会存在从 PeopleTable 到 AddressTable 的关系。这非常适合视图 1。一个查询将为二级导航提供数据，该查询的结果可以包括向下钻取所需的关系数据。

但是，如果我想支持视图 2，我将不得不根据关系的方向和我从哪里开始执行两个查询。

如果您将此扩展到具有更多表和字段的更大数据集，我的担忧可能会变得更加明显。因为我想在初始辅助导航项创建中实际提供来自关系父级的一些数据。因此，这意味着对该表进行初始查询以列出项目，并对每个单独的项目进行查询（从关系中的父项获取我需要的数据）以完成初始列表中显示的数据。（然后单击一个项目将提供更多详细信息）。显然，这种关系可以颠倒过来，然后我会提取子数据而不是父数据，但是当我想从另一个方向（另一个视图）获取数据时，我又会遇到同样的情况。

TL;DR：我需要能够在几乎任何方向上遍历表并钻取数据，同时尽量减少任何给定情况所需的查询数量。这是需要大量关系的情况吗？

找到问题的根源：我的理解是，虽然 Backendless 确实支持它们，但通常不赞成双向关系（至少在 SQL 世界中）。

那么，实际上，最佳实践是什么？这仅仅是一个合乎逻辑的“在帮助您减少查询时创建关系”吗？

【问题讨论】：

标签： database table-relationships backendless

【解决方案1】：

双向在这里也很不受欢迎，尽管它确实有效。您可能会发现一些错误，因为它使用得不多。

原因是它不是必需的，你已经知道你可以请求获取反向内容。

但是，您不应该使用它们的原因是，在您可能不使用它时自动加载所有额外数据比在您使用时发出显式请求更昂贵......

此外，您可以通过创建一个可以完成所有工作的自定义服务来限制查询对网络流量的影响。

【讨论】：

自动加载并不是我真正关心的问题。我关心跨表的相关记录。在每个表中都有一个包含其他表中关联记录的字段似乎更有效。因为我可以直接从特定地址记录中提取相关人员记录的确切 ID，而不必查询整个 PersonTable 来查找与该特定地址记录相关的所有记录。维护指向关联记录的指针似乎是一个较低级别的复杂性，我的理解是这就是 Backendless 中的关系。
只要自动加载数据就不需要查询关系了

【解决方案2】：

但是，如果我想支持 View 2，我必须执行两个给定关系方向和我在哪里的查询开始。

在 Backendless 中不一定要执行两个查询，因为查询语法支持“向后查找”。这意味着知道一个“子”对象，您可以使用“whereClause”的以下语法查找其父对象：

childRelation.objectId = 'childObjectId'

例如，对于您的 Person 和 Address 表，假设 Parent 表中的关系列称为“addresses”，并且它是一对多关系。那么发送到Person表的查询是：

addresses.objectId = 'specific-objectId-value-from-Address'

请记住，您可以使用 Backendless 控制台测试 whereClause 查询。这是一篇关于该功能的文章： https://backendless.com/feature-14-sql-based-search-for-data-objects-using-console/

希望这会有所帮助。

【讨论】：