Негативное влияние модели Django с множеством полей (75+ полей)

Я нахожусь в процессе создания веб-приложения, которое принимает пользовательский ввод и сохраняет его для извлечения и манипулирования данными. Есть по существу 100-200 статических полей, которые пользователь должен ввести для создания модели компании.

Я вижу, как я могу разбить модель компании на несколько моделей Django 1-к-1, которые отображаются на компанию следующим образом:

  • Общая компания
  • Пункт списка
  • Заметки компании
  • Финансовые показатели компании
  • Оценки компании

Но почему бы мне не создать одну модель компании с 200 полями?

Есть ли заметные компромиссы в производительности при попытке загрузить набор запросов?

По моему мнению, для вашей кодовой базы было бы разумно иметь несколько моделей, связанных друг с другом. Это даст вам больше возможностей для масштабирования и упростит навигацию по полям вашей модели. Также, когда вы захотите сделать пользовательский сериализатор или пользовательские представления, которые будут иметь дело с некоторыми из ваших полей, но не со всеми, было бы идеально не извлекать 100+ полей каждый раз.

Оказывается, я задавал неправильные вопросы. Вот вопросы, которые я задавал. Это скорее вопрос о базе данных, чем о Django, как мне кажется: Зачем использовать отношения 1 к 1 при проектировании базы данных?

С точки зрения логики, отношения 1:1 всегда должны быть объединяться в одну таблицу.

С другой стороны, могут существовать физические соображения для таких "вертикального разделения" или "разделения строк", особенно если вы знаете. что вы будете обращаться к некоторым столбцам чаще или в другом порядке. чем к другим, например:

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

С другой стороны, если вы говорите о "1:0 или 1" (а не об истинном 1:1), то это совершенно другой вопрос, заслуживающий другого ответа. ответа...

Вернуться на верх