Должен ли я использовать массив указателей или PFRelation? (parse.com)

Question

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

PFRelation *relation = ... 
PFQuery *query = [relation query]; 

Контекст: Я в здании приложение, в котором каждый экземпляр PFUser имеет множество экземпляров TennisGame (может быть большое количество), и экземпляры TennisGame имеет множество экземпляров PFUser (2 или 4, в зависимости от того, это игра в одиночку или игра в парные разряды).

Вопрос: Каков наилучший способ организации моих данных на parse.com? Я рассматривал PFRelation в классе PFUser (для экземпляров TennisGame), а также массив или 2 или 4 указателя в классе TennisGame (для экземпляров PFUser). Но мне нужны оба? Если нет, то что лучше?

Answer 1

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

• Нужно ли включать теннисные игры пользователя, когда вы получаете пользователя? Если да, массивы поддерживают include по запросам. Вы не можете сделать include с отношениями, и вам нужно сделать еще один запрос для доступа к теннисным играм пользователя.
• Сколько TennisGames будет у пользователя в max? Если он, вероятно, будет более 100 (рекомендуемый лимит в Parse), лучше идти с отношениями. Поскольку массивы не масштабируются до больших отношений.
• Как вы указали, это важный для вас порядок? Если да, массивы поддерживают порядок.
• И снова, как вы сказали, если вам интересно подмножество данных, отношения могут ограничивать запросы, а массивы - нет.

Предлагаю вам посмотреть this video о взаимоотношениях Парса из дней разработки Парса.

Кроме того, вам не нужно поддерживать отношения с обеих сторон. Это затруднит создание и обновление.