Что предпочесть в GQL; StringListProperty или ListProperty? - PullRequest
0 голосов
/ 12 января 2011

Я создаю приложение со многими отношениями; Элемент объекта «Изображение» может быть связан с любым количеством галерей («Галерея»). И, конечно, галерея может содержать любое количество изображений.

Итак, следуя предложению Google здесь, я буду использовать список в «Picture», который содержит внешние ключи «Gallery». Это подход BigTable.

(Подход Реляционного БД старого стиля заключался бы в размещении таблицы / сущности между «Рисунок» и «Галерея».)

Вот мой вопрос: при хранении Ключа я должен использовать «StringListProperty» для «Picture» или «ListProperty (db.Key)» будет работать лучше?

Одна причина, по которой я вижу StringList , заключается в том, что я могу хранить и другие значения, кроме Keys, но с другой стороны, в любом случае это будет грязный стиль. Но я также почти уверен, что Google предложил не использовать более одного Списка на объекте, потому что Индекс (ы) взорвется. Так что это будет держать меня в черном ходу.

Что касается ListProperty с типом " Ключ ", одной точкой будет автоматическая проверка, если значение фактически является Ключом.

Поскольку преобразовать строки в ключи очень просто, и наоборот, я не вижу причин для предпочтения одного из типов списка здесь.

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

Любопытно ваше мнение. Особенно, если кто-то проверил производительность на этом или был бы так добр и сделал это.

Cheers, // Ханнес

Ответы [ 2 ]

0 голосов
/ 20 января 2011

Используйте db.ListProperty (db.Key), это облегчит выборку данных, чем строку. Если модель галереи имеет свойство pic_list типа db.ListProperty (db.Key), которое содержит список ключи объекта изображения .. Предположим, что Picture - это имя вашего объекта .. тогда Picture.get (// GalleryObject //. pic_list) получит все объекты изображения ..

0 голосов
/ 13 января 2011

Используйте db.ListProperty(db.Key), если вы собираетесь хранить списки ключей.Они будут храниться в двоичном представлении, которое является более компактным, чем строковое представление, которое вы использовали бы в списке строк.

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

...