1

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

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

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

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

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

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

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

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

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

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

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

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

所以，真的，什么是最佳实践？它只是一个合乎逻辑的“当它们帮助您减少查询时创建关系”？

4

2 回答 2

0

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

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

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

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

于 2016-06-02T19:25:16.540 回答
0

但是，如果我想支持 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/

希望这可以帮助。

于 2016-06-03T15:46:14.500 回答