Ефективно прилагане на връзката "един към много" с Python NDB

Бих искал да чуя вашето мнение относно ефективното прилагане на връзката "един към много" с Python NDB. (напр. Човек(един) към задачи(много))

Според мен има три начина за прилагането му.

  1. Използвайте аргумента „родител“.
  2. Използвайте „повтарящо се“ структурирано свойство
  3. Използвайте свойство „повторен“ ключ

Обикновено избирам начин въз основа на логиката по-долу, но има ли смисъл за вас? Ако имате по-добра логика, моля, научете ме.

  1. Използвайте аргумента „родител“.

    • Transactional operation is required between these entities
    • Необходима е двупосочна препратка между тези обекти
    • Силно намерение за връзката „родител-дете“.

  2. Използвайте „повтарящо се“ структурирано свойство

    • Don't need to use 'many' entity individually (Always, used with 'one' entity)
    • 'много' обект се посочва само от 'един' обект
    • Броят на „повторените“ е по-малък от 100

  3. Използвайте свойство „повторен“ ключ

    • Need to use 'many' entity individually
    • 'много' обект може да бъде препратен от други обекти
    • Броят на „повторените“ е повече от 100

No.2 увеличава размера на обекта, но можем да запазим операциите на хранилището за данни. (Трябва да използваме заявка за проекция, за да намалим времето на процесора за десериализацията). Затова използвам този начин, доколкото мога.

Наистина ценя вашето мнение.


python google-app-engine app-engine-ndb
person Chikashi Kato    schedule 06.02.2013    source източник
comment
Задачата има KeyProperty, сочеща към Person, питате, за да намерите задачи за person?   -  person tesdal    schedule 07.02.2013
comment
Това е опция №4, която @dragonx отговори, нали? Ако трябва да направя заявка за задачи за хора и трябва да приемем, че хората имат много задачи, използвам тази опция. Също така го използвам в случай на извличане на част от стойностите на имотите.   -  person Chikashi Kato    schedule 07.02.2013

Отговори (2)


arrow_upward
7
arrow_downward

Ключово нещо, което пропускате: Как четете данните?

Ако показвате всички задачи за даден човек при заявка, 2 има смисъл: можете да направите запитване към лицето и да покажете всичките му задачи.

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

Има четвърта опция, която е да използвате KeyProperty във вашата задача, която сочи към вашето лице. Когато имате нужда от списък със задачи за човек, можете да подадете заявка.

Ако трябва да търсите отделни задачи, вероятно ще искате да изберете #4. Можете да го използвате и в комбинация с #3.

Също така, броят на повтарящите се свойства няма нищо общо със 100. Той има всичко общо с размера на вашите обекти Person и Task и колко ще се побере в 1 MB. Това е потенциално опасно, защото ако вашият обект Задача потенциално може да бъде голям, може да ви свърши мястото във вашия обект Лице по-бързо, отколкото очаквате.

person dragonx    schedule 06.02.2013
comment
Здравей @dragonx, благодаря ти за отговора! Да, „Как се четат данните“ е много важно. Ако имам нужда от част от стойностите на повтарящото се структурирано свойство (напр. задачи, маркирани с „важно“), може да искам отделни обекти, поради времето на процесора за десериализация. Освен това не взех предвид ограничението от 1MB. Благодаря ви, че го посочихте. Искам да изясня една точка. Запитването „с“ повтарящи се структурирани свойства НЕ е ужасно, нали? За запитване към обектите App Engine използва индекс. Следователно цената на заявката е същата като при заявка с други свойства. Греша ли? - person Chikashi Kato; 07.02.2013
comment
Цената на заявката не е проблем. Има някакво странно поведение при заявки за повтарящи се структурирани свойства. Ще трябва да сте внимателни и да ги заобиколите. Прочетете внимателно документите за свойствата и заявките на ndb. developers.google.com/appengine/docs/python/ndb/ developers.google.com/appengine/docs/python/ndb/ - person dragonx; 07.02.2013
comment
Благодаря ви за отговора, @dragonx! Определено да. Заявките за повтарящи се структурирани свойства са малко трудни. Трябва да внимавам, когато заявката е задължителна. - person Chikashi Kato; 07.02.2013
comment
Съжалявам, има още нещо, което забравих да спомена. Отвъд ограничението от 1MB на обект, има ограничение за броя на индексираните свойства на обект, мисля 5000. Това е още едно нещо, ако използвате повтарящи се структурирани свойства, вярвам, че можете да дъвчете тези 5000 индексирани свойства по-бързо от вас бих очаквал. Внимавайте и с това. - person dragonx; 08.02.2013
comment
Благодаря ти за информацията, @dragonx. Напълно съм забравил ограничението на индекса за търсене. Не мислех, че се изразходва много бързо. Ще проверя отново внимателно документацията. Вашето предложение е наистина полезно. - person Chikashi Kato; 08.02.2013

arrow_upward
6
arrow_downward

Едно нещо, което повечето потребители на GAE ще осъзнаят (рано или късно) е, че хранилището за данни не насърчава дизайна според формалните принципи за нормализиране, които биха се считали за добра идея в релационните бази данни. Вместо това често изглежда, че насърчава дизайн, който е неинтуитивен и анатема за установените норми. Въпреки че принципите на проектиране на релационни бази данни имат своето място, те просто не работят тук.

Мисля, че основата за дизайна на хранилището за данни вместо това попада в два въпроса:

  1. Как ще прочета тези данни и как да ги прочета с минималния брой операции за четене?

  2. Дали съхраняването му по този начин ще доведе до експлозия в броя на операциите за запис и индексиране?

Ако отговорите на тези два въпроса с възможно най-много предвидливост и реални тестове, мисля, че се справяте доста добре. Бихте могли да формализирате други правила и конкретни случаи, но тези въпроси ще работят през повечето време.

person Sudhir Jonathan    schedule 07.02.2013
comment
Благодаря ви за отговора, @sudhir-jonathan. Тези два въпроса са много смислени. Винаги трябва да ги имам предвид. Разбирането на характеристиките и използването на данните е абсолютно важно за моделирането на хранилището за данни. - person Chikashi Kato; 07.02.2013