Просмотрите мою модель Django - нужно много предложений

Question

Я использую различные источники информации, чтобы создать профиль человека. Как только я сделаю это, я хочу проявить гибкость, чтобы взглянуть на человека по-другому. У меня нет большого опыта в django, поэтому я хотел бы критиковать (быть нежным) моей модели. По общему признанию, даже когда я кодировал это, я думаю избыточность (против СУХОГО), но я хотел бы знать, что думают другие. FWIW - эти данные были извлечены, а не созданы - так что, возможно, мне не следует хранить все это, но удаление данных кажется плохим ..

В частности, я хочу знать, подходит ли использование ManyToMany или вы просто поцелуетесь и оставляете каждую запись как свою собственную без какого-либо участия в ManyToMany. В долгосрочной перспективе я думаю, что KISS сделает его обновление простым (базовым для цикла), но есть ли компромисс с возможностью запрашивать человека (скажем, на основе location_description или job_function). Во всяком случае, я был бы признателен за некоторый вклад.

class Person(models.Model):

    """This simply builds a notes user"""

    aliases = models.ManyToManyField(Aliases)  #Hmm this is list..
    assistant = models.CharField(max_length = 255, blank = True)
    cell_phone = models.CharField(max_lenth = 16, blank = True)
    city = models.ManyToManyField(City)
    country = models.ManyToManyField(County)
    department = models.ManyToManyField(Department)
    departmeht_number = models.ManyToManyField(Department_Number)
    division_code = models.ManyToManyField(Division_Code)
    email = models.EmailField(max_length = 50)
    functional_area = models.ManyToManyField(Functional_Area)
    # jpeg = models.
    job_classification = models.ManyToManyField(Job_Classification)
    job_classification_code = models.ManyToManyField(Job_Classification_Code)
    last_name = models.CharField(max_length = 255)
    location_description = models.ManyToManyField(Location_Description)
    location_path = models.ManyToManyField(Location_Path)
    mail_address = models.CharField(max_length = 255, blank = True)
    mail_domain = models.ManyToManyField(Mail_Domain)
    mail_file = models.CharField(max_length = 255, blank = True)
    mail_server = models.ManyToManyField(Mail_Server)
    match_pct = models.CharField(max_lenth = 6)
    name = models.CharField(max_length = 255)
    name_reverse = models.CharField(max_length = 255)
    nickname = models.CharField(max_length = 32)
    notes_url = models.URLField()
    #    object_class = models.
    office_phone = models.CharField(max_length = 255, blank = True)
    other_phone = models.CharField(max_length = 255, blank = True)
    position = models.ManyToManyField(Position)
    section = models.ManyToManyField(Section)
    section_code = models.ManyToManyField(SectionCode)
    shift = models.ManyToManyField(Shift)
    state = models.ManyToManyFiedl(State)
    supervisor = models.ManyToManyField(Supervisor)
    supervisor_reverse = models.ManyToManyField(Supervisor_reverse)
    uid = models.CharField(max_length = 128)

    def __unicode__(self):
        return str(self.name)

Answer 1

__unicode__ должен вернуть юникод

def __unicode__(self):
       return u'%s' %self.name

Django предоставляет поле электронной почты для полных адресов:

mail = models.EmailField()

Я думаю, что адресная модель может быть полна смысла. У человека может быть несколько адресов (работа, дом, ...)

1010 * редактировать * Я только что видел, вы используете emailfield. Что это за: mail_address = models.CharField(max_length = 255, blank = True) mail_domain = models.ManyToManyField(Mail_Domain) mail_file = models.CharField(max_length = 255, blank = True) mail_server = models.ManyToManyField(Mail_Server) редактировать

Вам не нужно постоянно пользоваться ManyToManyFields. Проверьте ForeignKey, OneToOneField и универсальный фреймворк

Answer 2

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

Например, у вас есть city и country как отдельные отношения. Это означает, что у вас может быть пользователь, имеющий city = ['Paris', 'London', 'New York'] и country = ['USA', 'France', 'UK'].

Вместо этого, я думаю, вам следует установить отношение locations ManyToMany, указывающее на модель, состоящую из city и country свойств.

То же самое с department и department_number, job_classification и job_classification_code, location_description и location_path и т. Д.

Редактировать: В некоторых случаях вы можете использовать ForeignKey вместо ManyToMany. Возможно, пользователь может принадлежать только одному city и country?

Position и supervisor, вероятно, будут некоторыми из более хитрых отношений, потому что position должен указывать на отдел / подразделение, а is_supervisor, вероятно, должно быть свойством позиции. То есть вам нужно всего лишь указать на позицию, поскольку супервизор (ы) будет извлечен из позиций других пользователей.

Редактировать : Пример: Если человек A работает в отделе X, а человек B также работает в отделе X, но в качестве менеджера, то лицо A контролируется лицом B.

Редактировать : Может возникнуть соблазн предположить, что в отделе может быть только один руководитель или что менеджер может управлять только одним отделом. Я бы посоветовал против этого, поскольку организации часто имеют все виды особых случаев. Подумайте о сценариях, например, когда менеджер уходит из компании, какое-то время отдел будет без менеджера, или другой менеджер временно вступит во владение, таким образом сохраняя две должности менеджера.

Answer 3

Вот несколько мыслей.

Я думаю, вы должны создать отдельные модели для department и job_classification и так далее. Например

class department(models.Model):
    name = Models.CharField(max_length=100)
    number = Models.IntegerField

, а затем отправьте поле ManyToManyField в отдел. В противном случае, если у вас есть человек с department = ['HR', 'Finance'] и department_number = [12, 5], я не думаю, что есть какой-либо способ сказать, какой номер отдела представляет какой отдел.

Мне было бы легче прочитать модель, если бы поля были сгруппированы по тому, что они описывают, а не по алфавиту. E.G Я думаю, что name, nickname, last_name должны быть определены вместе.

Наконец, возможно, псевдоним должен быть отдельной моделью с ForeignKey до Person, поскольку только один человек должен иметь какой-либо конкретный псевдоним.

Answer 4

Я бы сделал подчиненное поле и удалил бы супервизора.

 subordinates = models.ManyToManyField('self', related_name='supervisors', through=Position)

Таким образом, у руководителей будет поле автоматического обратного просмотра, и будет запись о позиции, которая соединяет руководителя с подчиненным

edit: На самом деле, я бы также посоветовал тщательно подумать о перепроектировании ваших моделей. Может быть, вам не нужно столько, сколько вы предлагаете.

Похоже, у вас есть "отдел", "компания" (если вам нужно отслеживать несколько компаний), "должность", "местоположение" и "человек" ... Решите, какие крупные объекты сохранить, а затем подумайте, где именно Каждое поле принадлежит и как связать «большие» объекты, которые будут преобразованы в таблицы.

Вероятно, будет лучше установить отношения подчиненного-супервизора между объектами Позиции, потому что люди приходят и уходят, но позиция более постоянна. Так что я бы имел:

class Position:
    title = models.CharField() #product manager, engineer, etc.
    employee = models.ForeignKey(Person, related_name='positions')
    subordinates = models.ManyToManyField('self', related_name='supervisors')

из, если вам не нужно несколько супервизоров на позицию, используйте

    supervisor = models.ForeignKey('self', related_name='subordinates')

Несмотря на то, что поле subordiantes теперь отсутствует, оно будет доступно, как и ранее, через соответствующее имя.

Куда относится местоположение?

Если вы решите, что и у сотрудника, и у отдела должно быть местоположение, то вы можете подумать о родовых отношениях, хотя с ними и не так легко работать, как с «обычными», но вы также можете избежать добавления «типа» location ('private / business'), а затем используйте Location.company или Location.residence_owner и избегайте использования общих отношений.

Answer 5

Я бы также предложил вам использовать отдельную модель для трудоустройства. Используйте внешний ключ обратно к вашему объекту Person. Вы можете добавить столько записей в эту таблицу, сколько необходимо.

То же самое относится и к полям mail_ *.