2013-08-08 2 views
1

В настоящее время я создаю приложение для клиента, в котором каждая запись содержит большое количество различных частей информации (около 50-60 полей), связанных с ней.Организация сложных моделей Django

Я хочу разбить модель на разделы, чтобы данные были немного структурированы.

Моя первая попытка сделать что-то вроде этого:

class Program(models.Model): 
    class BookingInformation(models.Model): 
     program = models.OneToOneField('Program', related_name='booking_information') 

     producer = models.CharField(max_length=100, blank=True) 
     producer_phone = models.CharField(max_length=30, blank=True) 

     ... 

    class Editorial(models.Model): 
     program = models.OneToOneField('Program') 

     series = models.CharField(max_length=100, blank=True) 

     ... 

У меня есть 5 или около секций, а некоторые из них являются вложенными.

Таким образом, я мог бы иметь программный объект и делать program.booking_information.producer, чтобы попасть в это поле. Также я могу более легко использовать ModelForm, чтобы иметь отдельные формы для каждого из разделов (что-то, что мне хотелось бы).

Сложность возникает, когда я создаю объект. Потому что, когда я создаю объект программы, объект Program.BookingInformation еще не существует, и я не могу выполнить его без предварительного сохранения программы (поэтому он получает первичный ключ). И тогда я читал такие вещи, как this which appear to discourage the use of OneToOneFields, когда они не являются абсолютно необходимыми.

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

+0

[Zen of Python] (http://www.python.org/dev/peps/pep-0020/) - Квартира лучше, чем вложенная. Кроме того, я сомневаюсь, что здесь действительно нужны вложенные модели. – karthikr

+0

@ karthikr, не могли бы вы объяснить, почему? – joerick

+0

Независимо от того, насколько сложны модели, я не вижу необходимости в вложенных моделях. Вы можете переосмыслить его и построить плоскую структуру. Трудно сказать, что измениться, не зная о приложении/видя модели. – karthikr

ответ

1

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

Что можно, чтобы разделить различную «группу» данных в отдельные абстрактные модели, которые вы все наследующие:

class BookingInformation(models.Model): 
    # fields 

    class Meta: 
     abstract = True 

class Program(BookingInformation, Editorial, etc.): 
    pass 

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

Чтобы получить отдельные формы, которые вы хотите, вы можете указать несколько ModelForm классов, каждый из которых имеет свой собственный fields вариант определен:

class BookingInformationForm(forms.ModelForm): 
    class Meta: 
     fields = ['producer', 'producer_phone', etc] 

Это потребовало бы большинство, если не все поля модели имеют null=True или blank=True, в зависимости от конкретного поля, для предотвращения проблем при создании модели с формой, которая имеет только подмножество полей модели.

+0

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

Смежные вопросы