Моделирование данных в App Engine. Дочерние объекты и стиль документа

Question

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

Вот пример:

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

Один объект, содержащий структуры данных, хранящиеся в виде JSONblob:

Один из способов сделать это - сохранить коллекцию 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'

Вариант использования:

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

Цель отношений между родителями и дочерними объектами:

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

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

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

Существует ли нормальный и общепринятый способ обработки данных такого рода в google app engine?

Answer 1

Взгляните на новый NDB API (в частности, StructuredProperty: http://code.google.com/appengine/docs/python/ndb/properties.html#structured)

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

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

Answer 2

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

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