Поддерживает ли Python Django пользовательские SQL и денормализованные базы данных без отношений внешнего ключа?

Question

Я только начал изучать Python Django и имею большой опыт создания сайтов с высоким трафиком с использованием PHP и MySQL.Что меня беспокоит до сих пор, так это чрезмерно оптимистичный подход Python к тому, что вам никогда не понадобится писать собственный SQL, и он автоматически создает все эти связи внешнего ключа в вашей базе данных.Одна вещь, которую я узнал за последние несколько лет построения Chess.com, это то, что невозможно НЕ писать собственный SQL, когда вы имеете дело с чем-то вроде MySQL, которому часто нужно указывать, какие индексы следует использовать (или избегать)и что иностранные ключи являются смертным приговором.Самой сильной рекомендацией Percona было удаление всех FK для оптимальной производительности.

Есть ли способ в Django сделать это в файле моделей?создавать отношения без создания фактических ФК БД?Или есть способ начать на уровне базы данных, спроектировать / создать мою базу данных, а затем попросить Django перепроектировать файл моделей?

Answer 1

Необработанный SQL так прост:

for obj in MyModel.objects.raw('SELECT * FROM myapp_mymodel'):
    print obj

Денормализация базы данных зависит от вас во время определения модели.

Вы можете использовать нереляционные базы данных (MongoDB, ...) тоже с Django NonRel

Answer 2

Если вам не нужны внешние ключи, избегайте использования

• models.ForeignKey(),
• models.ManyToManyField() и
• models.OneToOneField().

Django автоматически создаст поле int с автоматическим приращением с именем id, которое можно использовать для ссылки на отдельные записи, или вы можете переопределить его, пометив поле как primary_key=True.

Существует также документация по выполнению необработанных SQL-запросов к базе данных .

Answer 3

Я согласен с рекомендацией «без внешних ключей» (с заявлением об отказе: я также работаю в Percona).

Причина, по которой это рекомендуется, заключается в параллельности / уменьшении внутренней блокировки.

Продажа может быть сложной «оптимизацией», но если вы считаете, что в базе данных есть транзакции (и более или менее совместимы с ACID), то это должны быть только ошибки логики приложения, которые вызывают нарушения внешнего ключа. Не сказать, что они не существуют, но, если вы включите внешние ключи в разработку, надеюсь, вы найдете хотя бы несколько ошибок.

С точки зрения того, нужно ли вам писать собственный SQL:

Объяснение, которое я обычно даю, состоит в том, что «оптимизация редко уменьшает сложность». Я думаю, что по-прежнему можно использовать ORM по умолчанию, но если в профилировщике это выглядит так, как будто одна конкретная часть функциональности отнимает гораздо больше времени, чем вы подозреваете, если бы она была написана от руки, тогда вам нужно быть готовым к исправлению это (при условии, что код вызывается достаточно часто).

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

Answer 4

Вы можете просто создать файл model.py и избежать автоматического создания таблиц SQL Alchemy, предоставляя вам возможность самостоятельно определять фактические таблицы.Таким образом, хотя в файле model.py существуют отношения внешнего ключа, это не означает, что они должны существовать в реальных таблицах.Это очень хорошая вещь, учитывая, как в MySQL реализованы смехотворные ограничения внешнего ключа - MyISAM просто игнорирует их, а InnoDB создает необязательный индекс для каждого независимо от того, имеет ли это смысл.

Answer 5

django-admin inspectdb позволяет вам реконструировать файл моделей из существующих таблиц. Это только очень частичный ответ на ваш вопрос;)