У Google App Engine, яка найефективніша модель приєднання багатьох до багатьох?

Дизайн BigTable відкидає багато філософій стандартних реляційних моделей, явно віддаючи перевагу денормалізації великому безлічі крихітних таблиць.

Однією з найбільших областей, де ця проблема є, є моделювання приєднань багатьох до багатьох.

Один із способів моделювання цих об'єднань - це порушення першої нормальної форми та розміщення всіх цікавих даних у db.ListProperty (). Хоча це має можливість пошуку за запитом, я ще не вивчив наслідки для продуктивності пошуку списку порівняно з витягненням іншої таблиці.

Як долучаються не представляється можливим, то це можливо таблиці зв'язків через RelationshipProperties. Таким чином, при достатньому дотриманні зусиль можна створити стандартну таблицю перетину (таблицю із спільним первинним ключем, на яку посилаються обидва батьківські таблиці). Хтось досліджував хіти ефективності різних реалізацій?

-Edit-

Хоча Список ключів, запропонований у документації, дійсно є одним із способів цього зробити, я зацікавлений у швидкості роботи та аномалії цієї та інших реалізацій. Чи є корисність у створенні взаємних списків ключів? Чи зусилля, що беруть участь у повторному, коштує? Чи є кращий спосіб це зробити?

Я також зараз працюю з магазином даних GAE, ви повинні перевірити цю статтю, якщо ви ще цього не зробили. Якщо ви знайшли щось корисне, будь ласка, оновіть своє запитання.

Редагувати:

Я знайшов це сьогодні, перевірити.

На моєму досвіді в GAE, ви повинні використовувати запити таблиць досить щадно. Додавання таблиці "приєднання" просто уповільнить все ще більше. Наприклад, якщо у вас є таблиці A і B, які мають спільний зв'язок між багатьма, і ви створюєте таблицю "приєднання" J з полями RelationshipProperty до A і B, вам доведеться запитувати J щоразу, коли ви хочете знайти пов'язані записи (суб'єкти).

Було б набагато швидше створити Список ключів в A або B (або обидва за потреби), оскільки вони будуть включені, коли ви отримаєте цей запис / сутність. Поки у вас не надто багато ключів у списку (тобто сутність не надто велика), це шлях.

Я почав використовувати ndb у своїх додатках, і є деякі суттєві переваги від використання ключів під час отримання об'єктів. Якщо сутність вже кешована, вона спочатку витягне її з пам'яті чи пам'яті. Отже, якщо у ваших списках ключів є суттєве перекриття, витяги будуть набагато швидшими для тих, хто вже отримав.