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

Я хотел бы услышать ваше мнение об эффективной реализации отношений "один ко многим" с NDB Python. (например, Person (one)-to-Tasks (many))

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

Использовать аргумент 'parent'
Использовать "повторное" структурированное свойство
Использовать свойство "repeat" Key

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

Используйте аргумент 'parent'
- Транзакционная операция требуется между этими объектами
- Двунаправленная ссылка требуется между этими объектами
- Сильно намерены отношения "родитель-ребенок"
Используйте 'repeat' Структурированное свойство
- Не нужно использовать "много" сущность отдельно (всегда, используется с "одной" сущностью)
- "много" сущность ссылается только на "единую" сущность
- Число повторений меньше 100
Использовать свойство 'repeat' Key
- Необходимо использовать индивидуальность "много"
- "много" сущность может передаваться другими объектами.
- Число повторений более 100

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

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

Ответ 1

Ключевое значение, которое вам не хватает: как вы читаете данные?

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

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

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

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

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

Ответ 2

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

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

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

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