Рекомендация модели данных хранилища данных GAE для вложенных отношений "одного вида" - PullRequest
0 голосов
/ 19 февраля 2019

Я прошел через Книжное приложение учебник (в файле node.js) от Google и вместо каталога книг я хотел бы смоделировать каталог производственных деталей.

Где часть состоит из«sub» -части и задачи.Каждая «под» -часть может иметь снова «под-части» и задачи (этапы производства).

Текущая реализация : На данный момент у меня есть только два вида Детали и Задачи .Отношения между частями управляются через свойство, хранящее уникальный ключ (parentId) родительской части в ее дочерней части.Более сильная головная боль, которую я испытываю в данный момент (например), заключается в том, что изменение цены вложенной вложенной детали будет рекурсивно необходимо обновить все родительские части ...

Вопрос: будет рекомендованным дизайном хранилища данных для такого приложения?

Это должно решить или сделать его более эффективным:

  • Если я изменю цену "sub-sub-sub" -parts на этонеобходимо изменить цену всех родительских частей в соответствии с выбранной методологией расчета.
  • Не следует ограничивать глубину вложенных частей (я читал ограничения для хранилища данных "значения вложенных объектов" вбыть 20 (но, вероятно, не понял его правильно).
  • Не должен быть ограничен 1 записью в секунду для (части и всех ее частей) "группы сущностей". Я читал об этом ограничении, ноЯ не уверен, относится ли это также к так называемым транзакциям (что, я думаю, вы можете делать с группами сущностей).

1 Ответ

0 голосов
/ 21 февраля 2019

Одно из возможных решений - избегать полного хранения совокупных цен в Datastore.Вместо этого «цена» для каждой части или задачи должна включать только стоимость самой вещи, но не ее частей.

Вместо этого вычисляйте цену на лету, когда необходимо, складывая все деревочасти / подразделы / задача.Сохраните его в memcache, если вы хотите ускорить расчеты (но обязательно удалите ключ memcache при обновлении цен).

...