YP977,

тынц
тынц 2

YP977Работает с базами Postgres и SQLiteМежду разными СУБД сравнивать схемы, ИМХО, смысла не имеет, поскольку все равно упрешься в различия архитектур.

YP977Для Postgresql и SQLite ничего нормального не нашел и поэтому написал.Тогда по-порядку:
1. Для какой задачи нужно сравнение схем?
2. Что имеется в виду под сравнением схем?
3. Требуется ли сравнивать "в обе стороны" или только "чего не хватает"?
4. Требуется ли сравнивать не только лишь структуру таблиц, но и порядок следования полей в ней?
5. Требуется ли сравнивать ХП, функции, пакеты?

YP977Для Postgresql и SQLite ничего нормального не нашел и поэтому написал.Чем не устроили найденные решения?

YP9771. Есть программный продукт работающий с базой. Серверная часть работает с Postgres, клиентская с SQLite. Базы на 90% похожие. В процессе разработки новых версий продукта базы меняются. Если кратко, то необходимо подготавливать ALTER скрипты для обновления баз на более свежую версию. Объектов в базах не то, что бы много но каждый раз писать все ручками утомительно.
Для этой задачи, на мой взгляд, компарер не требуется.
Из опыта - мы занимались разработкой и поддержкой тиражируемого программного продукта. В базе были специализированные таблицы в которых прописывались версии структур (по предметным модулям). Доработка структур осуществлялась в рамках патчей, в которые входили скрипты изменения структур таблиц, вьюх, ХП и т.п., включая апдейты данных. Соответственно, в момент Х из протестированных доработок собирался патч, который также тестировали на накат и уже после этого устанавливался заказчику. Патч при установке менял версию в базе. Интерфейсная часть анализировала версию и предоставляла либо запрещала доступ при несоответствии версий. Такой подход позволял избежать бардака с разными версиями у клиентов. Если у клиента довольно старая версия, достаточно было накатить несколько патчей, вместо того чтобы актуализировать схему по компареру. Компарерами пользовались до того как пришли к этой схеме, даже писали свои. Как показывает опыт - компарер нужен в исключительных случаях (суровый клиентский админ решил самостоятельно изменить базу).

alexeyvgПопахивает мышкопрограммированием, никто ALTER не писал :-)
Ну и программированием наживую прямо в базе, без использования средств разработки.Да, сильно похоже. Ну если база одна и разработчик тоже, то такой подход будет вполне приемлем, в остальных же случаях нужно устранять организационный бардак, а не пытаться устранять его последствия.

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