Ни в коем случае не пушить туда-сюда.
- В идеальном случае ваш проект должен поддерживать миграции:
- Каждая ревизия кода, которая нарушает совместимость с БД относительно предыдущей, должна содержать скрипт миграции. В этом скрипте создаётся структура, модифицируются старые данные, переименовываются поля и т.д. Иногда такие скрипты делают двунаправленными, чтобы поддерживать обратные миграции.
- В БД нужно хранить версию или номер ревизии, которой соответствует текущее состояние БД.
- При запуске приложения нужно проверять версию и выполнять цепочку миграций, необходимых для приведения версии к требуемому состоянию.
Так вы можете добиться того, чтобы продуктовая БД была отдельно, тестовая отдельно, девелоперская отдельно. Очень плохая идея работать на девелоперской машине с данными из продовой базы. Так происходят утечки перс-данных.
Монга - это schema less БД, которая толерантно относится структуре коллекций и не валится при запросе несуществущих полей. Нужно стараться писать код максимально толерантно к отсутствию наполнения БД.
В любом случае у вас в БД есть обычно:
- структура (в случае монги, как я уже сказал, это не так важно)
- справочники
- пользовательские данные
- производные данные (кэш), которые можно безболезненно удалить, а затем они перегенерятся сами по мере запросов.
Нужно писать код так, чтобы он всю структуру и технические справочники, отсутствующие в предоставленной БД и необходимые для работы, умел инициализировать сам. Или, на худой конец, сделайте команду или скрипт init_db.
Если какие-то тестовые данные нужны для тестов или отладки, то можно сделать скрипт, который заполнит БД ими. Это называется фикстуры.
Никогда не храните код в БД. Всякие хранимые процедуры и прочее в БД - это зло. Код должен быть в системе контроля версий, а БД к этому не приспособлены. Если уж нужны хранимки, то храните их в системе контроля версий и заливайте их в БД при инициализации или миграциями.
Простой
Простой
