Я пытаюсь обернуть голову вокруг групп сущностей в Google AppEngine. Я понимаю их в целом, но так как это звучит так, как будто вы не можете изменить отношения после того, как объект создан, и у меня есть большая миграция данных, я хочу попытаться сделать это правильно с первого раза.
Я создаю художественный сайт, на котором участники могут зарегистрироваться как обычный постоянный участник или как один из нескольких неполиморфных «типов» сущностей (Artist, Venue, Organization, ArtistRepresentive и т. Д.). Например, художники могут иметь Artwork, который, в свою очередь, может иметь другие отношения (Галерея, Медиа и т. Д.). Все эти вещи связаны через ссылки, и я понимаю, что вам не нужны группы сущностей, чтобы просто делать ссылки. Тем не менее, некоторые ссылки должны существовать, поэтому я смотрю на группы сущностей.
Из документов:
«Хорошее эмпирическое правило для групп сущностей заключается в том, что они должны иметь размер данных одного пользователя или меньше».
Тем не менее, у меня есть пара, надеюсь, да / нет вопросов.
Вопрос 0: я так понимаю, вам не нужны группы сущностей только для транзакций. Однако, поскольку группы объектов хранятся в одной и той же области большой таблицы, это помогает сократить проблемы согласованности и условия гонки. Это честный взгляд на группы сущностей и транзакции вместе?
Вопрос 1. При сохранении дочернего объекта неявным образом получают доступ или сохраняются какие-либо родительские объекты? Т.е., если я создаю Группу сущностей с помощью пути Member / Artist / Artwork, если я сохраняю объект Artwork, обновляются ли объекты Member и Artist? Я думаю, что нет, но я просто проверяю.
Вопрос 2: Если ответ на вопрос 1 - «да», доступ / обновление только перемещаются вверх по дорожке и не влияют на других детей. Т.е., если я обновляю Artwork, никакие другие дочерние элементы Artwork Участника не обновляются.
Вопрос 3: Предполагая, что очень важно, чтобы Участник и связанный с ним объект типа учетной записи существовали, когда пользователь регистрируется, и что только пользователь будет обновлять его Член и связанный объект типа учетной записи Entity, имеет ли смысл поместить их в Группы сущностей вместе?
т.е. Участник / Исполнитель, Участник / Организация, Участник / Место проведения.
Аналогичным образом, при условии, что только пользователь сможет обновлять объекты Artwork, имеет ли смысл их включать? Примечание. Мультимедиа / галерея / и т. Д., Являющиеся ссылками на художественные работы, могут относиться ко многим художественным работам, а не только к тем, которые принадлежат пользователю (т. Е. Отношения многих ко многим).
Имеет смысл иметь все пользовательские биты в группе сущностей, если она работает так, как я подозреваю (т.е. Q1 / Q2 - «нет»), поскольку все они будут в одной и той же области BigTable. Однако добавление графического объекта в группу сущностей может привести к нарушению принципа «держать его маленьким» и, честно говоря, может не потребовать участия в транзакциях, за исключением сохранения пропускной способности / повторных попыток при загрузке изображений графического объекта.
Есть мысли? Я неправильно обращаюсь к группам сущностей?