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

Короче говоря, ваши опасения безосновательны. Вы должны «организовать» свою базу данных по проектам, чтобы использовать термин Django. Каждая модель в каждом приложении будет иметь свою таблицу, но все они будут в одной базе данных. Помещение их в отдельную базу данных - не лучшая идея по целому ряду причин, самая главная из которых заключается в том, что вы не можете выполнять запросы по базам данных.

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

Если вы собираетесь много возиться со своими моделями во время разработки, лучше всего использовать фикстуры для быстрой загрузки данных после запуска синхронизации. Или, если вы собираетесь изменить несколько обязательных полей, затем напишите быстрый Python, чтобы создать для вас фиктивные данные.

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

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

Что касается того, что вы не доверяете свои данные двоичным файлам, простой "pg_dump" даст вам текстовую версию ваших данных. Мне кажется, что вы работаете над своим приложением с данными реального времени, что является ошибкой. Ваша цель должна заключаться в том, чтобы ваше приложение было построено, работало и протестировано на поддельных данных или, по крайней мере, на копии ваших производственных данных, а затем, когда вы уверены, что все в порядке, перенесите его в производство. Здесь пригодятся такие вещи, как юг, поскольку вы можете автоматизировать это развертывание, и это поможет вам обработать любые изменения таблиц / столбцов базы данных, которые вам нужно внести.

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

Что касается того, что вы не доверяете свои данные двоичным файлам, простой "pg_dump" даст вам текстовую версию ваших данных. Мне кажется, что вы работаете над своим приложением с данными реального времени, что является ошибкой. Ваша цель должна заключаться в том, чтобы ваше приложение было построено, работало и протестировано на поддельных данных или, по крайней мере, на копии ваших производственных данных, а затем, когда вы уверены, что все в порядке, перенесите его в производство. Здесь пригодятся такие вещи, как юг, поскольку вы можете автоматизировать это развертывание, и это поможет вам обработать любые изменения таблиц / столбцов базы данных, которые вам нужно внести.

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

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

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

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

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

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

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

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

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

Обычно я просто сбрасываю модуль

>>> python manage.py reset blog

, это сбрасывает все таблицы в INSTALLED_APPS.blog

Я не уверен, что это ответит на ваш вопрос, но это гораздо менее разрушительно, чем очистка БД.

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

Однако когда ваш сайт перейдет в рабочую среду, у вас будет немного больше Работа. Любые изменения, которые вы вносите в свои модели, которые должны быть отражены в базе данных, должны быть отправлены как SQL и запущены вручную в базе данных. Существует функция django-admin.py для выдачи предложенного SQL, который вы можете использовать для создания сценария для запуска в базе данных для его миграции. Как вы уже упоминали, приложение для миграции, такое как South, может быть здесь полезным, но это не является строго необходимым.

Что касается разделения сайтов, запускайте их как отдельные сайты / проекты. У вас может быть отдельный файл настроек для каждого проекта, который позволяет запускать две разные базы данных. Это контрастирует с запуском двух сайтов как отдельных приложений в одном проекте. Если они полностью разделены, они, вероятно, не должны быть в одном проекте, если вам не нужно использовать общий код.