Данные моделирования в App Engine. Дочерние сущности и стиль документа

Попытка смоделировать некоторые сильно связанные, но также иерархические данные в движке приложения.

Вот пример:

Person:
    Phone Numbers:
        Number: 555-555-5555, Ext: 123, Notes: Work
        Number: 444-444-4444, Ext: 456, Notes: Mobile

Один объект, содержащий структуры данных, хранящиеся в виде больших двоичных объектов JSON:

Один из способов сделать это - сохранить коллекцию phone_numbers как неиндексированный большой двоичный объект текста JSON, а затем добавить свойство поиска, чтобы человека можно было запросить по номеру телефона:

p_entity = Person()

p_entity.phone_numbers = dbText(simplejson.dumps([{'Number':'555-555-5555', 'Ext':'123', 'Notes':'Work'},{'Number':'444-444-4444', Ext:'456', Notes:'Mobile'}]))
p_entity.phone_numbers_search_property = ['5555555555', '4444444444']

p_entity.put()

Несколько объектов с родительско-дочерними отношениями:

Другой способ - использовать дочерние и родительские сущности:

person_entity = Person()
person_entity.put()

phone_entity1  = PhoneNumber(parent=person_entity)
phone_entity.Number = '5555555555'
phone_entity.Ext    = '123'
phone_entity.Notes  = 'Work'

phone_entity2  = PhoneNumber(parent=person_entity)
phone_entity.Number = '4444444444'
phone_entity.Ext    = '456'
phone_entity.Notes  = 'Mobile'

Пример использования:

Это сильно связанные данные. Объект человека содержит несколько телефонных номеров. Но телефонные звонки также можно совершать на эти номера телефонов и с них. Записи телефонных звонков также должны ссылаться на эти номера телефонов.

Цель отношений родительско-дочерних сущностей:

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

Однако могут ли они быть уместными и в этом случае? Почти так же эффективно вытащить родительский элемент и все его дочерние элементы из хранилища данных, как вытащить одну сущность с ее «дочерними элементами», хранящимися в виде текстовых BLOB-объектов JSON?

Основной вопрос

Есть ли нормальный и приемлемый способ обработки таких данных в движке приложений Google?


person Chris Dutrow    schedule 12.03.2012    source источник


Ответы (2)


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

Должны ли измениться ваши записи телефонных звонков при изменении номера телефона? Моя первоначальная мысль заключалась в том, что записи должны содержать отдельную копию данных телефонного номера, а не ссылку на объект телефонного номера. Вы по-прежнему можете запросить журнал вызовов по номеру телефона. Имеет смысл хранить ссылку на задействованные контакты, чтобы в случае изменения их имени или чего-то еще, журнал вызовов мог быть обновлен.

person Riley Lark    schedule 12.03.2012
comment
Привет, Райли, большое спасибо за твой ответ! Да, я тоже сохраняю телефонные номера в записях звонков, но я также возвращаюсь к записи телефонных номеров, с которых был сделан звонок. Таким образом, если кто-то меняет свой «РАБОЧИЙ» номер, я знаю, что звонок был сделан на «РАБОЧИЙ» номер, но я также знаю фактический номер, который был вызван. - person Chris Dutrow; 12.03.2012

Обратите внимание на новый API NDB (в частности, на StructuredProperty: http://code.google.com/appengine/docs/python/ndb/properties.html#structured)

Кроме того, исходя из моего опыта и того, что я читал, когда вы обновляете существующую сущность, вы не платите за запись в свойства, которые не изменились, то есть, в отличие от того, что сказал Райли, вы будете платить только за запись объекта. + 2 записи для любых индексированных свойств, которые были изменены + 1 запись для каждого составного индекса, который у вас есть, который содержит модель и свойства, которые вы изменили.

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

person someone1    schedule 12.03.2012
comment
Re. обновление существующих свойств: правда? Я бы хотел, чтобы ты был прав. Можете ли вы указать мне на документы, в которых указано, что вы не платите за недвижимость, которая не изменилась? - person Riley Lark; 12.03.2012
comment
Я не могу найти точную документацию, но посмотрите ответ Ника Джонсона на этот вопрос: stackoverflow.com/questions/8113363/. Ник является членом команды App Engine и я считаю его надежным источником по этому поводу. Я также считаю, что Гвидо упомянул об этом в группе Google NDB. Честно говоря, моя математика неверна, количество операций записи - 4 на измененное свойство, а не 2. - person someone1; 12.03.2012
comment
Ах, красиво. Это сэкономит мне много денег;) - person Riley Lark; 12.03.2012
comment
Думаю, это не очень хорошо задокументировано. К счастью, все это происходит за кулисами, поэтому вы извлекаете из этого пользу независимо от того, знаете вы об этом или нет, но, тем не менее, вы можете принимать более обоснованные решения по моделированию, зная информацию. - person someone1; 12.03.2012
comment
Намного ли лучше использовать NDB, чем API PYTHON напрямую? Я использовал структуру сущностей ORM для создания приложения несколько лет и имел плохой опыт, поэтому я немного сдержан, когда дело касается ORM. - person Chris Dutrow; 14.03.2012
comment
NDB - это просто новый API хранилища данных Python. Это означало улучшение / замену google.appengine.ext.db. Он предлагает дополнительные функции и оптимизацию по сравнению со старым API. Вы используете API хранилища данных напрямую, минуя даже библиотеку google.appengine.ext.db? - person someone1; 14.03.2012
comment
В поддержку комментария Райли Ларк (App Engine не взимает плату за свойства, которые не меняются), см. Также Платежная страница в официальной документации: там говорится, что стоимость размещения существующего объекта (на объект), т. е. обновления, составляет 1 запись + 4 записи на измененное значение индексированного свойства. + 2 записи на каждое измененное значение составного индекса - person AngularChef; 10.07.2012