Движок приложения моделирование данных многие ко многим

Question

У меня есть вопрос относительно того, как смоделировать отношение многие ко многим в App Engine:

У Blogentry может быть много тегов, тег может применяться ко многим записям в блоге.

Я вижу пару сценариев:

1. Использование набора строк в качестве атрибута в записи блога.

   • Это позволяет мне легко запрашивать запись, используя тег
   • Это не позволяет мне выбирать все теги и их веса (к скольким записям они относятся)

2. Использование неизвестных отношений между Entry и классом Tag (Набор ключей для тегов в классе Entry и наоборот)

   • Это позволяет мне выбрать все теги и их вес
   • Это намного сложнее поддерживать
   • Являются ли атрибуты Set загруженными, или я бы каждый раз получал весь граф объекта? (Получить запись, которая выбирает несколько тегов, каждый из которых, в свою очередь, выбирает несколько записей)

3. используйте 1., но сохраняйте данные о тегах и их весах отдельно

   • При этом возникают проблемы синхронизации между данными тегов и тегами в записях

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

Answer 1

Как и многие другие системы управления базами данных, отношения «многие ко многим» изначально не поддерживаются в хранилище данных App Engine, но могут быть решены с помощью «таблицы соединений». Однако, поскольку язык запросов App Engine не поддерживает объединения, это будет очень болезненно использовать в вашем приложении. Архитектура Google BigTable фактически препятствует этому, потому что распределенные объединения не эффективны.

Итак, я предлагаю придерживаться правила "будь проще, глупый"; используйте самую простую вещь, которая работает. Список строк в объекте «Blogentry» звучит довольно надежно. Даже если он подвержен гоночным условиям (люди делают параллельные обновления, перезаписывают изменения друг друга), но сколько людей у ​​вас все равно редактируют один и тот же пост в блоге?

Answer 2

Я решил пойти с вариантом 3., чтобы вести отдельный список тегов с их весами.

Кажется, это работает нормально, хотя код вставки / обновления немного загроможден.