Comments 6
ECM7.Migrator использует другой подход к версионированию, чем ваша утилита. Тут нужно писать классы-миграции, которые будут описывать изменение структуры при переходе между версиями.
Ваша же утилита предназначена для синхронизации двух разных версий структуры БД.
Если говорить в терминах статьи «Версионная миграция структуры базы данных: основные подходы», то вашу diff-утилиту нужно использовать при реализации «Метода уподобления структуры БД исходному коду», а ECM7.Migrator реализует что-то близкое к «Методу инкрементных изменений».
Ваша же утилита предназначена для синхронизации двух разных версий структуры БД.
Если говорить в терминах статьи «Версионная миграция структуры базы данных: основные подходы», то вашу diff-утилиту нужно использовать при реализации «Метода уподобления структуры БД исходному коду», а ECM7.Migrator реализует что-то близкое к «Методу инкрементных изменений».
Вами была проделана большая работа и в результате получилось отличное приложение. Если бы мне нужно было привести к заданному виду произвольную БД, вряд ли я нашел бы утилиту лучше Вашей (во всяком случае, среди бесплатных вариантов).
Как правильно заметил Shedal в комментарии выше, Вы используете немного другой подход, чем мы (и эти подходы решают разные проблемы).
Я не совсем понял, зачем нужно парсить синтаксис и куда нужно переводить простые запросы. Скорее всего, данный функционал нужен для решения задач, возникающих при Вашем подходе и не возникающих в случае использования «метода инкрементных изменений».
Как правильно заметил Shedal в комментарии выше, Вы используете немного другой подход, чем мы (и эти подходы решают разные проблемы).
Я не совсем понял, зачем нужно парсить синтаксис и куда нужно переводить простые запросы. Скорее всего, данный функционал нужен для решения задач, возникающих при Вашем подходе и не возникающих в случае использования «метода инкрементных изменений».
Кстати, можете ответить на пару вопросов о Вашей утилите?
— можно ли с помощью Вашей утилиты автоматизировать процесс развертывания БД? правильно ли я понял, что для каждой БД нужно сначала руками получить скрипт для преобразования, а потом руками его выполнить?
— как Ваша утилита при переименовании колонки (или таблицы) определяет, что нужно переименовать объект БД, а не удалить старый и создать новый?
— можно ли с помощью Вашей утилиты автоматизировать процесс развертывания БД? правильно ли я понял, что для каждой БД нужно сначала руками получить скрипт для преобразования, а потом руками его выполнить?
— как Ваша утилита при переименовании колонки (или таблицы) определяет, что нужно переименовать объект БД, а не удалить старый и создать новый?
Синтаксис нужен (нам), например для перевода VIEW, при миграции логики на другую БД.
Автоматизации нет. Утилита скорее отображение API, который мы готовили для основного проекта. В ней все руками. Вы же понимаете: автоматически удалять и изменять структуру — опасно для здоровья :) Мы сознательно не делали такой возможности.
Переименования нет. Честно вы меня озадачили… Если колонку переименовывают — она же не является тем же объектом, т.е. отследить никак кроме указки пользователя. Если есть такая возможность — подскажите.
Ну и напоследок у меня к вам вопрос: какой практический смысл хранить историю изменений БД?.. Могу предположить, для последовательной обработки данных (помимо структуры), доведения до финального результата?
Автоматизации нет. Утилита скорее отображение API, который мы готовили для основного проекта. В ней все руками. Вы же понимаете: автоматически удалять и изменять структуру — опасно для здоровья :) Мы сознательно не делали такой возможности.
Переименования нет. Честно вы меня озадачили… Если колонку переименовывают — она же не является тем же объектом, т.е. отследить никак кроме указки пользователя. Если есть такая возможность — подскажите.
Ну и напоследок у меня к вам вопрос: какой практический смысл хранить историю изменений БД?.. Могу предположить, для последовательной обработки данных (помимо структуры), доведения до финального результата?
Как я и писал, наши утилиты используют разные подходы и решают разные проблемы. Я задал эти вопросы, чтобы узнать, насколько утилита, решающая Ваши проблемы, сможет нам помочь в наших проблемах.
На счет истории: храня историю изменений мы, по сути, храним не только информацию о финальной структуре БД, но и о всех промежуточных ее состояниях. Это дает нам возможность легко перевести БД из любого состояния в любое другое состояние (например, любую версию БД обновить до последней версии).
Кроме того, когда разработчик описывает изменения БД, он пишет их не для неизвестной произвольной БД, а для БД заданной версии и он четко знает, в каком состоянии эта БД находится. Например, если мы пишем изменения для перевода БД с версии 4 на версию 5, мы просто пишем коменду «удалить колонку» (без всяких проверок), т.к. можем быть уверены, что в версии 4 эта колонка существует. Таким образом, мы можем очень легко описывать изменения, которые сами по себе получаются очень простыми. Это положительно сказывается на надежности и легкости отладки и поиска ошибок в процессе изменения БД.
Собственно, проблема переименования объектов БД при нашем подходе не возникает в принципе. Если объект нужно переименовать, мы просто пишем команду «переименовать», т.к. мы можем быть точно уверены, что в данной версии существует исходный объект с исходным названием. Т.е. мы явно задаем, какое действие нужно сделать с объектом.
На счет истории: храня историю изменений мы, по сути, храним не только информацию о финальной структуре БД, но и о всех промежуточных ее состояниях. Это дает нам возможность легко перевести БД из любого состояния в любое другое состояние (например, любую версию БД обновить до последней версии).
Кроме того, когда разработчик описывает изменения БД, он пишет их не для неизвестной произвольной БД, а для БД заданной версии и он четко знает, в каком состоянии эта БД находится. Например, если мы пишем изменения для перевода БД с версии 4 на версию 5, мы просто пишем коменду «удалить колонку» (без всяких проверок), т.к. можем быть уверены, что в версии 4 эта колонка существует. Таким образом, мы можем очень легко описывать изменения, которые сами по себе получаются очень простыми. Это положительно сказывается на надежности и легкости отладки и поиска ошибок в процессе изменения БД.
Собственно, проблема переименования объектов БД при нашем подходе не возникает в принципе. Если объект нужно переименовать, мы просто пишем команду «переименовать», т.к. мы можем быть точно уверены, что в данной версии существует исходный объект с исходным названием. Т.е. мы явно задаем, какое действие нужно сделать с объектом.
Sign up to leave a comment.
Миграции БД для .NET — новый ECM7.Migrator