Базы данных

Существует несколько причин, по которым видеоруководство побуждает вас перейти с SQLite на сервер баз данных, такой как MySQL или PostgreSQL:

1. SQLite великолепен, но не очень хорошо масштабируется, если вы ожидаете большой трафик
.
2. SQLite не работает, если вы хотите распределить ваше приложение по нескольким серверам. Возвращаясь к Heroky, если вы обслуживаете свое приложение на нескольких Dynos, у вас возникнут проблемы, потому что каждый Dyno будет использовать отдельную базу данных SQLite. Если вы отредактируете что-то через админку, это произойдет в одной из этих баз данных, случайным образом, что приведет к несоответствиям
.
3. Некоторые функции Django недоступны на SQLite

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

Однако, как правило, он не подходит для производственных веб-сайтов. Кроме того, хотя может возникнуть соблазн хранить файл sqlite.db вместе с кодом, например, в git-репозитории, это считается плохой практикой, поскольку ваша база данных может содержать конфиденциальные данные (такие как пароли, имена пользователей, электронные письма и т.д.). Следовательно, строгое разделение кода и данных является хорошей практикой.

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

Даже если вы можете удалить публичный доступ к некоторым файлам через GitHub, это не очень хорошая практика, потому что когда вы работаете в команде с несколькими разработчиками, разработчики могут иметь доступ к коду, но не к производственным данным, потому что они обычно конфиденциальны. Если вы работаете с 5 людьми и у каждого из них есть копия вашей базы данных, это означает, что риск потерять ее или украсть в 5 раз выше ;)

Статические файлы

Когда вы работаете локально, встроенная команда Django runserver выполняет за вас обслуживание статических активов, таких как CSS, Javascript и изображения.

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

Поэтому вам нужно разместить эти статические файлы в другом месте, и AWS - это одно из мест, где вы можете это сделать. AWS будет обслуживать эти файлы для вас, причем очень эффективным способом. Есть и другие варианты, например, настройка обратного прокси с Nginx для обслуживания файлов, если вы используете выделенный сервер.

<<<Насколько я могу судить, прогресс, который вы описываете в видео, ведет вас от локальной среды разработки к более эффективной и масштабируемой производственной установке. Этого и следовало ожидать, потому что не так сложно начать с чего-то действительно простого (SQLite, встроенный в Django

), а затем перейти к более сложным и абстрактным темам и инструментам.runserver