GAE: Какая лучшая практика для структурирования хранилища моделей - PullRequest
Новая
       15

GAE: Какая лучшая практика для структурирования хранилища моделей

0 голосов
/ 28 февраля 2019

Так что я использую реляционные базы данных в течение последних 3 лет, и у меня возникли некоторые проблемы с мышлением при создании баз данных noSql.У меня есть следующие модели: 

class Account(ndb.Model):
    first_name = ndb.StringProperty()
    last_name = ndb.StringProperty()
    email = ndb.StringProperty()
    password = ndb.StringProperty()


class Organisation(ndb.Model):
    org_name = ndb.StringProperty()
    org_address = ndb.StringProperty()
    .. and so on

class UserProfile(ndb.Model):
    user = ndb.KeyProperty(kind='Account')
    organisation = ndb.KeyProperty(kind='Organisation')
    role = ndb.StringProperty()

Учетная запись x Организация технически является отношением многие ко многим, поэтому UserProfile действует как таблица ссылок, как в реляционных базах данных

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

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

Просто запутанный в том, как это сделать, любая помощь или объяснение, где я иду не так, была бы признательна.

1 Ответ

0 голосов
/ 28 февраля 2019

Мне не нужно было делать более 1 запроса, чтобы получить информацию о сущности

Ну, в вашем примере это не так - дополнительные поиски (не запросы)) для сбора информации об организациях, которые отличаются сущностями от сущностей профилей пользователей, к которым вы запрашивали.

Но у вас есть 2 общих (и противоположных) идеи:

  • использовать ndb.KeyProperty для ссылки на другие объекты при моделировании отношений 1-ко-многим и многие-ко-многим: минимальная / не дублирующаяся информация, поэтому не требуется синхронизация / обслуживание, но требуется несколько запросов / поисков дляагрегированная информация, распределенная по нескольким объектам

  • клонировать требуемую информацию прямо в соответствующих объектах (возможно, использовать Структурированные свойства ?) - обеспечивая более быстрый доступ (дополнительные запросы / поиски не требуются)чтобы получить информацию), но синхронизация / обслуживание требуется, когда клонированная информация должна быть обновлена.

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

Лично я склоняюсь к 1-му, если это возможно.И когда я сталкиваюсь со случаями, когда возникает необходимость в нескольких запросах / поисках, я всегда дважды проверяю, действительно ли необходимо одновременное использование информации из нескольких сущностей (может быть, приемлемо отобразить детали организации, например, на отдельном экране?).Но это только личное предпочтение.

...