Эффективная реализация связи «один ко многим» с Python NDB

Я хотел бы услышать ваше мнение об эффективной реализации связи «один ко многим» с Python NDB. (например, человек (один) к задачам (многим))

В моем понимании есть три способа его реализации.

  1. Использовать «родительский» аргумент
  2. Использовать «повторяющееся» структурированное свойство
  3. Использовать повторяющееся свойство ключа

Обычно я выбираю способ, основываясь на приведенной ниже логике, но имеет ли он смысл для вас? Если у вас лучше логика, пожалуйста, научите меня.

  1. Использовать «родительский» аргумент

    • Transactional operation is required between these entities
    • Между этими объектами требуется двунаправленная ссылка
    • Твердое намерение отношений «родитель-ребенок»

  2. Использовать «повторяющееся» структурированное свойство

    • Don't need to use 'many' entity individually (Always, used with 'one' entity)
    • «многие» сущности ссылаются только на «одну» сущность
    • Количество «повторяющихся» меньше 100

  3. Использовать повторяющееся свойство ключа

    • Need to use 'many' entity individually
    • «многие» объекты могут быть переданы другими объектами
    • Количество повторов больше 100

№ 2 увеличивает размер объекта, но мы можем сохранить операции хранилища данных. (Нам нужно использовать проекционный запрос, чтобы сократить время процессора для десериализации). Поэтому я использую этот способ столько, сколько я могу.

Я очень ценю ваше мнение.


python google-app-engine app-engine-ndb
person Chikashi Kato    schedule 06.02.2013    source источник
comment
Задача имеет KeyProperty, указывающую на человека, вы запрашиваете поиск задач для человека?   -  person tesdal    schedule 07.02.2013
comment
@dragonx ответил на вариант №4, не так ли? Если мне нужно запросить задачи для людей, и нам нужно предположить, что у людей много задач, я использую эту опцию. Также я использую его в случае получения части значений свойств.   -  person Chikashi Kato    schedule 07.02.2013

Ответы (2)


arrow_upward
7
arrow_downward

Ключевой момент, который вы упускаете: как вы читаете данные?

Если вы отображаете все задачи для данного человека по запросу, 2 имеет смысл: вы можете запросить человека и показать все его задачи.

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

Есть четвертый вариант, который заключается в использовании KeyProperty в вашей задаче, которая указывает на вашего человека. Когда вам нужен список задач для человека, вы можете сделать запрос.

Если вам нужно искать отдельные задачи, то вы, вероятно, захотите использовать № 4. Вы также можете использовать его в сочетании с № 3.

Кроме того, количество повторяющихся свойств не имеет ничего общего со 100. Оно полностью связано с размером ваших сущностей Person и Task и тем, сколько их может поместиться в 1 МБ. Это потенциально опасно, потому что если ваша сущность Task потенциально может быть большой, у вас может закончиться место в сущности Person быстрее, чем вы ожидаете.

person dragonx    schedule 06.02.2013
comment
Привет @dragonx, спасибо за ответ! Да, «Как читать данные» очень важно. Если мне нужна часть значений повторяющихся структурированных свойств (например, задачи, помеченные как «важные»), мне могут понадобиться отдельные объекты из-за времени ЦП для десериализации. Кроме того, я не учел ограничение в 1 МБ. Спасибо, что указали на это. Я хочу уточнить один момент. Запрос с повторяющимися структурированными свойствами НЕ ужасен, не так ли? Для запроса сущностей App Engine использует index. Поэтому стоимость запроса такая же, как и при запросе с другими свойствами. Я ошибся? - person Chikashi Kato; 07.02.2013
comment
Стоимость запроса не является проблемой. Существует некоторое странное поведение при запросе повторяющихся структурированных свойств. Вы должны быть внимательны и работать вокруг них. Внимательно прочитайте документы по свойствам и запросам ndb. developers.google.com/appengine/docs/python/ndb/ developers.google.com/appengine/docs/python/ndb/ - person dragonx; 07.02.2013
comment
Спасибо за ответ, @dragonx! Определенно да. Запросы к повторяющимся структурированным свойствам немного сложны. Мне нужно быть осторожным, когда требуется запрос. - person Chikashi Kato; 07.02.2013
comment
Извините, есть еще одна вещь, которую я забыл упомянуть. Помимо ограничения в 1 МБ на объект, существует ограничение на количество проиндексированных свойств на объект, я думаю, 5000. Это еще одна вещь, если вы используете повторяющиеся структурированные свойства, я считаю, что вы можете пережевывать эти 5000 проиндексированных свойств быстрее, чем вы ожидал. Будьте осторожны и с этим. - person dragonx; 08.02.2013
comment
Спасибо за информацию, @dragonx. Я совершенно забыл об ограничении поискового индекса. Не думал, что расходуется очень быстро. Я внимательно перепроверю документацию. Ваше предложение действительно полезно. - person Chikashi Kato; 08.02.2013

arrow_upward
6
arrow_downward

Одна вещь, которую большинство пользователей GAE поймет (рано или поздно), заключается в том, что хранилище данных не поощряет разработку в соответствии с формальными принципами нормализации, которые считались бы хорошей идеей в реляционных базах данных. Вместо этого часто кажется, что дизайн неинтуитивен и противоречит установленным нормам. Хотя принципы проектирования реляционных баз данных имеют место быть, здесь они просто не работают.

Я думаю, что в основе дизайна хранилища данных лежат два вопроса:

  1. Как я буду читать эти данные и как мне их прочитать с минимальным количеством операций чтения?

  2. Приведет ли хранение таким образом к резкому увеличению количества операций записи и индексации?

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

person Sudhir Jonathan    schedule 07.02.2013
comment
Спасибо за ответ, @sudhir-jonathan. Эти два вопроса очень важны. Я должен помнить о них всегда. Понимание характеристик и использования данных абсолютно важно для моделирования хранилища данных. - person Chikashi Kato; 07.02.2013