Двунаправленные отношения в бездействии - Работа с очень взаимосвязанными данными

Question

Это фундаментальный вопрос на уровне начинающих, который не будет коротким. Это характерно для Backendless.

У меня есть ряд сценариев, которые я хотел бы иметь возможность обратиться, поскольку я работаю с небольшим набором таблиц, которые все взаимосвязаны в какой-то форме и их нужно исследовать с разных сторон.

Основным примером может быть нечто вроде PersonTable и AddressTable. PersonTable, содержащий список людей, с их lastName, firstName и т. Д. AddressTable, содержащий адреса и их различные атрибуты streetName, houseNumber и т. Д.

Предположим, я хочу предоставить пользователям два разных вида в основной навигации и разрешить им для дальнейшего расширения.

View1: Вы нажимаете «Люди», вы получаете список людей из PersonTable. Этот список появляется во вторичном навигационном окне. Нажатие на отдельное лицо предоставит вам адрес/адреса, связанные с этим человеком.

Однако, я также хочу, чтобы быть в состоянии сделать это в обратном порядке:

View2: Вы нажимаете кнопку «Адрес», вы получите список адресов из AddressTable. Этот список появляется во вторичном навигационном окне. Нажатие на отдельный адрес предоставит вам человека/людей, связанных с этим адресом.

Таким образом, с помощью однонаправленного подхода были бы отношения от PeopleTable до AddressTable. Это отлично и хорошо для View 1. Один запрос предоставит данные для дополнительной навигации, и результаты этого запроса могут включать данные отношений, необходимые для детализации.

Однако, если бы я хотел поддержать View 2, мне пришлось бы выполнить два запроса, учитывая направление отношений и где я начинаю.

Если вы масштабируете это до большего набора данных с большим количеством таблиц и полей, моя озабоченность может стать более очевидной. Потому что я хочу фактически предоставить некоторые данные от родителя отношения в начальном создании вторичного навигационного элемента. Таким образом, это означает исходный запрос этой таблицы для перечисления элементов и запрос для каждого отдельного элемента (для получения данных, которые мне нужны из его родителя в отношении), чтобы заполнить данные, указанные в исходном списке. (Тогда нажатие на элемент обеспечит еще более подробную информацию). Очевидно, что эта связь может быть отменена, и тогда я буду извлекать дочерние данные, а не родительские данные, но тогда, когда я захочу перейти к данным с другого направления (другой вид), я снова попаду в ту же ситуацию.

TL; DR: Мне нужно иметь возможность перемещать таблицы практически в любом направлении и сверлить данные, пытаясь минимизировать количество запросов, необходимых для этого случая. Это случай, когда требуется большое количество отношений?

В самом начале вопроса: Я понимаю, что, хотя Backendless поддерживает их, двунаправленные отношения, как правило, неодобрились (по крайней мере, в мире SQL).

Итак, действительно, что такое лучшая практика? Это просто логично «Создать отношения, когда они помогают вам сократить количество запросов»?

Answer 1

Двунаправленный тоже нахмурился, хотя он действительно работает. Вы можете найти несколько ошибок, поскольку они мало используются.

Причина в том, что это не требуется, вы уже знаете, что можете сделать запрос на получение обратного содержимого.

Но, по этой причине вы не должны использовать их в том, что автозагрузка все, что дополнительные данные, когда вы не можете использовать это является более дорогостоящим, чем делать явные запросы, когда вы делаете ...

Кроме того, вы можете ограничьте влияние своего запроса с точки зрения сетевого трафика, создав настраиваемую службу, которая работает на всех этапах работы.

Answer 2

Однако, если я хотел поддержать View 2, я должен был бы выполнить два запросы дали направление отношений и где я Отправной.

Выполнение двух запросов необязательно в Backendless, поскольку синтаксис запроса поддерживает «обратный поиск». Это означает, зная «ребенок» объект, вы можете поиск своего родителя, используя следующий синтаксис «WhereClause»:

childRelation.objectId = 'childObjectId' 

Например, для вашего лица и адреса, таблиц, предположите, что столбец отношения в таблице Parent называется «адреса», и это отношение «один ко многим». После этого запрос направляется в таблице Person является:

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

Имейте в виду, что вы можете проверить свои WhereClause запросы с помощью Backendless консоли. Вот статья об этой функции: https://backendless.com/feature-14-sql-based-search-for-data-objects-using-console/

Надеюсь, это поможет.