Должен ли я разделить таблицу на OneToOneField, если число столбцов слишком много? - PullRequest
Новая
       21

Должен ли я разделить таблицу на OneToOneField, если число столбцов слишком много?

1 голос
/ 01 октября 2019

У меня есть модель студента, в которой уже есть слишком много полей, включая имя, национальность, адрес, язык, историю поездок и т. Д. Студента. Это как показано ниже: 

class Student(Model):
    user = OneToOneField(CustomUser, on_delete=CASCADE)
    #  Too many other fields

У учащегося гораздо больше информации, которую я храню в других таблицах с отношением OneToOne к модели учащегося, например: 

class StudentIelts(Model):

    student = OneToOneField(Student, on_delete=CASCADE)
    has_ielts = BooleanField(default=False,)
    # 8 other fields for IELTS including the scores and the date
    # and file field for uploading the IELTS result

# I have other models for Toefl, GMAT, GRE, etc that 
# are related to the student model in the same manner through 
# a OneToOne relationship such as:

class StudentIBT(Model):

    student = OneToOneField(Student, on_delete=CASCADE)
    has_ibt = BooleanField(default=False,)
    # other fields

Должен ли яобъединить таблицы в одну таблицу или текущая схема базы данных подходит?

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

1 Ответ

2 голосов
/ 01 октября 2019

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

Однако есть несколько соображений, которые необходимо принять во внимание. account.

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

Ответ на этот вопрос довольно неплохо суммирует реальные физические причины разделения отношения 1: 1:

  • Вы можетехотите по-разному кластеризовать или разбить две таблицы «конечных точек» отношения 1: 1.
  • Если ваша СУБД позволяет это делать, вы можете разместить их на разных физических дисках (например, более критично для производительности на SSD). а другой - на дешевом жестком диске).
  • Вы измерили влияние на кеширование и хотите убедиться, что «горячие» столбцы хранятся в кеше, а «холодные» столбцы не «загрязняют» его.
  • Вам необходимо поведение параллелизма (например, блокировка), которое «уже», чем весь ряд. Это сильно зависит от СУБД.
  • Требуется разная защита для разных столбцов, но СУБД не поддерживает разрешения на уровне столбцов.
  • Триггеры, как правило, зависят от таблицы. Хотя теоретически вы можете иметь только одну таблицу и триггер игнорирует «неправильную половину» строки, некоторые базы данных могут накладывать дополнительные ограничения на то, что триггер может и не может делать. Например, Oracle не позволяет вам изменять так называемую «мутирующую» таблицу из триггера уровня строки - имея отдельные таблицы, только одна из них может изменяться, поэтому вы все равно можете изменить другую из своего триггера (но естьдругие способы обойти это).

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

точка зрения Джанго

Если выПосмотрите, как устроен Django, есть смысл разделить ваш стол на отношения один к одному. Одна из философий дизайна Джанго - «Слабая связь» . Что в экосистеме Django означает, что отдельным приложениям не нужно знать друг о друге для правильной работы. В вашем случае можно утверждать, что модель Студента не должна ничего знать о своих тестах IELTS, потому что если вы разделите эти два, модель Студента может быть повторно использована в каком-то другом приложении. Кроме того, некоторые функции, которые выполняют какой-то анализ по тестам IELTS, не должны «знать» что-либо о студенте, который прошел этот тест.

Однако используйте этот шаблон проектирования с некоторой осторожностью. Хороший вопрос, который нужно задать себе, не обязательно должен быть «Как столбцы могут быть в моей модели?», Потому что иногда есть веская причина иметь много данных в одной модели. Так что ответ «да» на один этот вопрос не обязательно заслуживает разделения ваших столов. Лучше задать себе вопрос: «Хочу ли я разделить обязанности / функциональность этих двух типов данных?», Что может быть по любой причине, например, возможность повторного использования или безопасность.

...