Почему в руководстве только одна база данных для приложений Django?

Мне нужно еще одно приложение на моем веб-сайте Django, но я не понимаю, как расширить свои знания из учебника.

Следуя уроку , структура моего проекта выглядит следующим образом:

- mydjango/
  - db.sqlite
  - firstapp/
  - mysite/

В учебнике говорится

… Приложение может находиться в нескольких проектах. …

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

  1. Как приложение может находиться в другом проекте? База данных проекта находится даже не в каталоге родительского проекта. Все просто смешано в одной базе данных.
  2. Почему у каждого приложения нет собственной базы данных?

🤔 А знаете ли вы, что...
Django предоставляет инструменты для создания адаптивных и мобильных приложений.


51
1

Ответ:

Решено

Как приложение может находиться в другом проекте? База данных проекта находится даже не в каталоге родительского проекта. Все просто смешано в одной базе данных.

Не все приложения находятся в каталоге проекта. На самом деле, вероятно, большинство ваших приложений этого не делают. django.contrib.auth, например, — это приложение, предлагаемое Django, которое находится в самом репозитории Django.

Многие пакеты Django экспортируют приложения django. Вы можете установить его, например, через pip, и, пока он находится в рамках интерпретатора Python, вы можете его импортировать.

Почему у каждого приложения нет собственной базы данных?

Вероятно, это была бы (очень) плохая идея: каждое приложение может работать с нулевой, одной или несколькими базами данных, а маршрутизация может осуществляться через маршрутизатор базы данных или с помощью .using(…) [Django-doc]. Многие модели, определенные в приложениях, связаны друг с другом. Например, у многих моделей есть внешний ключ к auth.User (модель User, определенная в приложении django.contrib.auth). Если бы они были определены в отдельной базе данных, вы не смогли бы применять FOREIGN KEY ограничения, не эффективно создавать JOIN и т. д., что сильно ограничило бы то, что вы можете делать с моделью.

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

По сути, Django стремится отделить логику приложения от базы данных. В настройке БАЗЫ ДАННЫХ [Django-doc] вы можете определить несколько баз данных, и это могут быть базы данных разных типов (PostgreSQL, MySQL, SQL Server, SQLite, MongoDB и т. д.). Затем, используя маршрутизатор базы данных [Django-doc] или явно указав базу данных в запросе, вы можете выбрать базу данных, которую хотите использовать, и, таким образом, даже, например, динамически переключаться. Django стремится быть инвариантным к диалектам, хотя это имеет некоторые ограничения. Таким образом, это означает, что если вы не используете расширенные функции базы данных, вы можете заменить один тип базы данных на другой, не меняя свой код. Приложения ортогональны базе данных: они сами по себе не имеют особого отношения к выбранной базе данных.