База данных и система управления версиями

#database #version-control #django-models #project-management

Вопрос:

Я работаю над проектом с платформой django и использую систему управления версиями для синхронизации моего кода с другими людьми. Но я не знаю, как организовать работу с базой данных. В django любой человек, работавший над проектом, может изменять модели django и указывать «syncdb» для синхронизации объектов модели с базой данных. Но другие люди не знают об этих изменениях, и это изменение кода может не сработать. Пожалуйста, подскажите мне несколько способов решения этой проблемы (может быть, другая бд или что-то другое).

Спасибо, и извините за мой английский 🙂

Ответ №1:

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

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

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

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

Ответ №2:

У вас должна быть начальная резервная копия базы данных под контролем verison. И после этого вы должны поместить все сценарии модификации в один и тот же контроль версий. Что-то вроде этого:

/База данных (в репозитории)

  • Первоначальная резервная копия
  • Script1_date.sql
  • Script2_date.sql

Комментарии:

1. По сути, это миграция бд.

Ответ №3:

Я не уверен, что понимаю вашу проблему; но помните, что в Django syncdb создает только новые таблицы. Это не изменяет существующую таблицу.

Если, например, вы просто добавите новое поле, база данных syncdb ничего не сделает.

Ответ №4:

На самом деле, рассматривая альтернативы, я часто удивляюсь, что никто не упоминает Юг

http://south.aeracode.org/

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

Ответ №5:

взгляните также на deltasql. вы можете протестировать его по адресу http://www.gpu-grid.net/deltasql (имя пользователя: пароль администратора: testdbsync ) и загрузить с http://sourceforge.net/projects/deltasql чао 🙂

Ответ №6:

Мне любопытно…что произойдет, если вы поместите свои файлы MDF и LDF под контроль исходного кода? Конечно, если ваши таблицы пусты и у вас просто есть структура базы данных…

Комментарии:

1. MDFS-это двоичные файлы, поэтому вы не можете по-настоящему различать их, чтобы увидеть изменения между версиями…

Ответ №7:

Похоже, вы хотите миграции.

В качестве примера: http://www.aswmc.com/dbmigration/

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

Комментарии:

1. Вот что syncdb делает. Его проблема в том, что программисты забывают запустить его.

2. Похоже, у них есть существующий дамп базы данных, и когда схема меняется, их база данных становится несогласованной. Похоже, он хочет, чтобы база данных оставалась согласованной… это миграции функциональные тесты. Функциональные тесты заставляют пользователей активно выяснять, что не так.