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

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

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

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

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

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

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

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

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

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

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

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

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

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

Django essentially aims to separate the application logic from the database(s). In the DATABASES setting [Django-doc], you can define multiple databases, and these can be different sorts of databases (PostgreSQL, MySQL, SQL Server, SQLite, MongoDB, etc.). Then by using a database router [Django-doc] or by specifying the database explicitly in a query, you can pick the database you want to use, and thus even dynamically switch for example. Django aims to be dialect-invariant, although this has some limitations, it thus means that if you don't use advanced database functionalities, you can trade one type of database for another without changing your code. Applications are orthogonal to the database: they don't per se have much to do with the database picked.

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