ListProperty для db.Key против «многие ко многим» в App Engine (особый случай)

Question

Я видел примеры с похожим вопросом. Но, пожалуйста, позвольте мне задать более конкретные вопросы, которые я хочу подтвердить мое понимание.

Мои вопросы:

1. Для ListProperty db.Key, если я могу предвидеть максимальное количество ключей, которые я хочу сохранить, сколько я должен НЕ превышать для хранения в ListProperty db.Key по сравнению с Ссылка на недвижимость? [Общий вопрос], потому что было не очень понятно, где страница App Engine говорит это,

   Другим более важным является то, что вы хотите избежать чрезмерного хранения большие списки ключей в ListProperty

2. Допустим, есть пользователи, которые могут следить за лентами активности ресторана. Следовательно, Пользователь может добавить столько ресторанов, сколько они хотят в свой список любимых. Есть модель пользователя и модель ресторана. Итак, я считаю, что любой пользователь не будет следовать более 30 ресторанов? что делает его ListProperty db.Key в качестве идеального решения?

Answer 1

Приведенные здесь соображения несколько размыты - жесткого ограничения нет, за исключением того, что общий (закодированный) объект не должен превышать 1 МБ.30 клавиш это совершенно нормально.100 все равно будет хорошо.В 500-1000 я бы начал волноваться.При 10 000 вы, вероятно, превысите лимит в 1 МБ.

Другое соображение состоит в том, что если вы ожидаете добавлять ключи в список по одному (каждый раз, читая и записывая сущность), вы в конечном итоге получаете O (N ** 2) земля, из-за которой ваши обновления начнут ползти очень медленно, вероятно, где-то между 100 и 1000 ключами.

Эти соображения одинаковы для всех ListProperties - ключи не являются специальными (цитата, которую вы далипросто происходит из статьи, которая фокусируется на ListProperty(db.key)).