Метод опционально вложенных моделей в Django

Question

Я создаю простое приложение для внутреннего отслеживания активов для своей компании. В настоящее время мы делаем это через Excel (ужасно). Я разобью это до:

Актив / Элемент - Инструмент, оборудование, детали и т. Д. Участок - Общее местоположение, в котором это находится: Объект A, Местоположение Участка B Контейнер - это место, где находится актив, это может быть здание, набор инструментов, ящик.

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

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

Answer 1

Есть две точки зрения, которые вы могли бы рассмотреть: 1. Легко ли читать модель, она не является избыточной и соответствует ли она вашей проблеме, 2. Какие запросы вы собираетесь запустить в модели.

Вы уже подумали о первом аспекте. Что касается второго, я считаю, что некоторые из запросов, которые вы хотите выполнить: 1. перечислить активы и связать их местоположение. 2. подсчитать активы на месте 3. перейдите в иерархию местоположений и перечислите все активы в каждом местоположении

Выше предлагается создать единую модель для местоположений, которая включает здания, мусорные ведра и т. Д., И дифференцировать их по полю location_type, который может быть внешним ключом для таблицы словаря (id, name). тогда для создания иерархии вам потребуется собственная ссылка на Foreign_key для родительского местоположения.

Таким образом, у вас будет один внешний ключ для местоположения из актива, и с учетом местоположения вы можете запросить asset_set напрямую. Любая другая модель будет менее прозрачной. Любая разница может быть устранена с использованием @property методов, например, чтобы сохранить поле, специфичное для построения, вы можете создать метод, который сначала проверяет правильность типа, а затем сохраняет значение в динамическом поле, например char_field_1

Вариант вышеизложенного. Если атрибуты для Bin, Building и т. Д. Слишком велики и различны для объединения в одну таблицу. Затем вы можете создать отдельные модели для каждого и иметь обнуляемое однозначное поле от местоположения до каждого. При сохранении вы можете проверить, что заполнено не более одного.