Возможно, вы там побывали: ваша команда работает над новыми функциями для вашего сайта, возможно, даже над его капитальным ремонтом, и вы очень рады, что наконец-то начнете жить и показать миру всю свою тяжелую работу. Но есть одна проблема: пока вы работали в своей среде разработки, вы внесли инкрементные изменения в схему своей базы данных, и эти изменения суммировались. Здесь новая таблица, там выпавший столбец, измененное ограничение… где-то ?? Пришло время перенести ваши старые данные в новую схему, но если вы не будете осторожны, вы легко можете впасть в яму отчаяния, которая является адом переноса данных!
Как мы здесь оказались?
Естественно, что при разработке программного обеспечения обычно создаются разные «среды» для каждого этапа разработки: тестирования, постановки, производства и т. Д. Каждая из этих сред будет иметь свою собственную кодовую базу и свой собственный набор ресурсов. Таким образом, команда может вносить изменения и подталкивать их к тестированию перед их фиксацией в производственной среде. Верно? Верно.
Все становится немного сложнее, когда в вашем проекте используется база данных, потому что каждой среде разработки потребуется собственный экземпляр базы данных, в противном случае данные вашей текущей действующей версии будут загрязнены тестами, проводимыми в других средах. Эти новые экземпляры базы данных, конечно, будут модифицированы с учетом потребностей новых функций или дизайна… не только для изменения данных, но и для изменения схемы самой базы данных. Если ваша команда внедряет систему Agile-разработки, вы можете себе представить, насколько сложно может быть отслеживание всех изменений, которые вносят все, когда они с нетерпением перемещают эти стикеры по большой доске.
GO-время
Когда, наконец, пришло время сделать большой шаг и воплотить в жизнь свой новый дизайн, перед вами встает загадка: как сделать так, чтобы все ваши унаследованные данные из исходной базы данных существовали в базе данных, которая отражает схему вашей базы данных разработки. Как это сделать? Один из вариантов - создать файл дампа существующих данных, а затем использовать его для повторного заполнения данных в новой базе данных с актуальной схемой. Эту стратегию иногда называют «сбросом на свалку». (Хорошо, на самом деле никто не относится к этому так.) Это действенная стратегия, но она может потребовать значительных затрат времени и ресурсов, в зависимости от структуры или данных.
«Миграция схемы» - еще один способ решения проблемы. Эта стратегия включает прямое манипулирование схемой исходной базы данных, чтобы она соответствовала схеме базы данных разработки. Хитрость заключается в том, чтобы не упустить ни одной мелочи при обновлении схемы. Часто это включает в себя открытие обеих баз данных и поиск взад и вперед (и назад и вперед) в поисках различий, которые вы могли пропустить.
"Должен быть способ получше!" Я слышу, как ты кричишь на свой монитор. Что ж, если вы можете позволить себе потратить немного денег на решение проблемы, коммерческие инструменты, безусловно, могут облегчить задачу. Redgate, например, помогает найти различия между двумя базами данных и позволяет пользователю выбирать, какие изменения следует зафиксировать. Flyway, еще один такой инструмент, выполняет ту же услугу с дополнительными функциями, такими как контроль версий. Эти инструменты недешевы, но они значительно упрощают перенос схемы.
Бесплатные решения с открытым исходным кодом?
Но как насчет скромного независимого разработчика с ограниченным бюджетом, скажете вы? Я рада, что вы спросили! Действительно, существует также ряд бесплатных инструментов с открытым исходным кодом, которые помогают разработчикам определять различия между схемами их различных баз данных. Одна полезная особенность, которую мы заметили, что все примеры, с которыми мы сталкивались, отсутствовали, однако (наряду со многими коммерческими вариантами, если на то пошло), была легко интерпретируемым визуализатором. Вот почему в интересах сообщества разработчиков мы разработали собственный инструмент Postgres «diffing», который мы с гордостью представляем миру: CHRISDIFFER - это кроссплатформенное настольное приложение с открытым исходным кодом для Mac и Windows, которое визуализирует текущее состояние двух баз данных Postgres с интуитивно понятными таблицами с цветовой кодировкой, представляющими схемы базы данных, с линиями между связями данных.
Пользователи могут легко понять схему каждой базы данных и выбрать, какие изменения они хотят внести в исходную базу данных. Простое нажатие на выделенные поля, показанные в визуализаторе, сгенерирует SQL-запросы, необходимые для соответствующего изменения таблиц. Подробнее об этом инструменте вы можете узнать на сайте CHRISDIFFER. Мы будем рады услышать отзывы о функциях, которые вы хотели бы увидеть ... или, что еще лучше, внесите изменения самостоятельно и отправьте запрос на перенос!
Мы гордимся CHRISDIFFER и надеемся, что он поможет еще нескольким людям избежать ада миграции баз данных!
Ресурсы:
