Дизайн класса Family Tree в Django

Я работаю над веб-приложением Family Tree с Django (в котором я новичок) и решаю, как разработать класс FamilyTree, чтобы пользователи могли иметь право просматривать/редактировать только определенные деревья.

В нынешнем виде у меня есть два абстрактных метакласса: Entity и Relation.

Объект может быть человеком или даже группой или событием. Отношение может быть родителем, братом, сестрой, партнером и т. д.

Отношение имеет внешние ключи "от" и "к", каждый из которых соответствует одному объекту. Поскольку абстракция мне понравилась больше, чем это предложение: Структура данных семейного древа, я решил хранить только личная информация в подклассе Person класса Entity. Доступ к отношениям осуществляется через «родственное имя». Если код требуется, пожалуйста, дайте мне знать. Мне нужно разрешение, чтобы опубликовать это.

Кажется, есть два основных способа разработки класса FamilyTree:

  1. Отношения ManyToOne из экземпляра FamilyTree ко всем сущностям, или ко всем отношениям, или к обоим.

  2. Отношение OneToOne к корневому объекту или отношению, из которого остальная часть дерева распаковывается во время сеанса.

Я не думал о каких-либо недостатках второго метода, который, похоже, ускорит работу.

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

Также:

  • Мысли о реализации, специфичные для Django.
  • Может быть, назначение разрешений только на основе FamilyTrees — не лучшая идея?

Заранее спасибо!


person AlexFADev    schedule 24.08.2015    source источник
comment
Насколько я понимаю вашу структуру, второй метод затруднит поиск разрешений, если разрешения (только) назначаются на уровне FamilyTree. Чтобы определить разрешение на редактирование для случайного человека или события или чего-либо (высокостоящего) в дереве, похоже, вам нужно разгадать все дерево, чтобы узнать, какому FamilyTree оно принадлежит, чтобы найти искомое разрешение.   -  person    schedule 24.08.2015
comment
Хорошая точка зрения. Если бы я кэшировал дерево после распутывания (в начале сеанса), этого было бы недостаточно?   -  person AlexFADev    schedule 24.08.2015
comment
Я не знаю; Я не знаю, насколько легко кэшировать дерево между запросами, и мне все еще кажется, что вам нужен какой-то структурированный способ обхода дерева, чтобы найти корневой элемент и соответствующие разрешения (я думаю, что нет прямого способа перейти от случайный элемент в дереве непосредственно к корневому элементу).   -  person    schedule 24.08.2015
comment
Я не использовал сеансы с тех пор, как некоторое время назад изучил PHP, но теоретически разве они не должны хранить данные на протяжении всего сеанса? Если бы вы распутали Древо и перечислили Лиц, это было бы легко проверить. Поправьте меня, если я ошибаюсь, но пользователь сможет только видеть/попытаться редактировать людей в своем соответствующем FamilyTree. Таким образом, переход от случайного человека обратно к корню (что было бы очень сложно) кажется маловероятным.   -  person AlexFADev    schedule 24.08.2015
comment
но пользователь сможет только видеть/попытаться редактировать людей в своем соответствующем FamilyTree. Точно сказать не могу. Если есть ссылка для редактирования, такая как /edit/tree/234/entity/567/, ее легко изменить вручную на /edit/tree/123/entity/1/, и я буду редактировать совершенно другого человека и дерево. Вы можете предотвратить это, только просмотрев разрешения для этого дерева (т. е. корневого объекта) в своем представлении. Конечно, здесь дерево находится в URL. Но что, если ссылки похожи на /edit/entity/567 и /edit/entity/1? Как мгновенно узнать, может ли пользователь редактировать объект 567 так же, как и объект 1?   -  person    schedule 24.08.2015
comment
Да, в этом случае потребуется сложный алгоритм обхода, и все преимущества варианта 2 во время выполнения будут потеряны. Как насчет необязательного поля базы данных, которое заполняется пользователем-владельцем при создании человека во время сеанса?   -  person AlexFADev    schedule 24.08.2015
comment
Куда будет прикреплено это необязательное поле?   -  person    schedule 24.08.2015
comment
Атрибут человека   -  person AlexFADev    schedule 24.08.2015
comment
Похоже, вы почти вернулись к варианту 1, хотя это поле, возможно, временное. Но тогда я бы выбрал явное лучше, чем неявное.   -  person    schedule 25.08.2015