Как организовать базу данных в Django с несколькими различными приложениями? - PullRequest
5 голосов
/ 21 декабря 2009

Я новичок в Django (и базах данных в целом), и я не уверен, как структурировать следующее. Источники данных, которые я буду иметь для моего сайта:

  1. блог
  2. для нескольких разных игр:
    • список рекордов
    • пользовательских уровней

Если бы я хранил данные в обычных файлах, у меня был бы только один файл для каждого из вышеперечисленных. В Django, в идеале (я думаю), у меня была бы отдельная база данных для каждого из них, но очевидно, что поддержка Django для нескольких баз данных еще не существует. Я беспокоюсь (излишне?) О сохранении всего в одной базе данных по двум причинам:

  1. Если я что-то напортачу в одном из разделов, я не хочу испортить остальные данные.

  2. Когда я работаю над одним из этих разделов, я бы хотел, чтобы у меня была возможность легко менять модель. Поскольку я узнал, что syncdb на самом деле не синхронизирует базу данных, я решил, что при работе с моделью проще всего просто стереть базу данных и начать все сначала. Опять же, я беспокоюсь о том, чтобы испортить другие разделы. Я посмотрел на на юг , и кажется, что на этапах планирования приложения возникает больше проблем, чем стоит (но я рассмотрю его позже, когда появятся действительно ценные данные).

Часть проблемы в том, что мне не очень удобно хранить мои данные в двоичном формате. Я привык к тексту, поэтому я могу легко его преобразовать, изменить в редакторе и т. Д., Не проходя через какой-то магический интерфейс базы данных (кстати, я использую postgresql).

Мои страхи необоснованны? Как люди обычно решают эту проблему?

Ответы [ 4 ]

9 голосов
/ 22 декабря 2009

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

Прежде всего, вам не нужно несколько баз данных для того, что вы делаете - одна сделает. Каждое приложение будет создавать свои собственные таблицы в базе данных, которые несколько изолированы друг от друга. Как упоминалось в czarchaic, вы можете выполнить python manage.py reset app_name для сброса только одного из них в случае изменения вашей модели. Однако вы потеряете эти данные.

Чтобы получить данные в относительно простом для работы с форматом формате, вы можете использовать команду python manage.py dumpdata > file_name.json, а затем перезагрузить ее позже python manage.py loaddata file_name.json. Вы можете использовать это для резервного копирования, локальных тестовых данных или для миграции бедного человека (подсказка: юг будет проще).

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

4 голосов
/ 22 декабря 2009

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

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

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

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

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

4 голосов
/ 22 декабря 2009

Я вообще просто перезагружаю модуль

>>> python manage.py reset blog

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

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

1 голос
/ 21 декабря 2009

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

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

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

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...