Часть процедуры установки продукта, над которым я работаю, устанавливает утилиту обновления базы данных. Утилита проверяет текущую версию базы данных пользователей и (при необходимости) выполняет серию операторов SQL, которые обновляют базу данных до текущей версии.
Две ключевые особенности этого распорядка:
Цель состоит в том, чтобы сделать процедуру настройки / базы данных как можно более простой для конечного пользователя (целевая аудитория не является технической). Однако я считаю, что в некоторых случаях эти две функции расходятся. Например, я хочу добавить уникальный индекс к одной из моих таблиц, но возможно, что существующие данные уже нарушают это правило. Я мог бы:
Мне ни один из вариантов не кажется привлекательным. Я мог пойти на компромисс и вообще не создавать уникальный индекс, но это было бы отстой. Интересно, что делают в этой ситуации другие?


Ознакомьтесь с SQL Packager от Red-Gate. Я лично не использовал его, но в целом эти ребята делают хорошие инструменты, и, похоже, они делают то, что вы ищете. Это позволяет вам изменить сценарий для настройки установки: http://www.red-gate.com/products/SQL_Packager/index.htm
Вы никогда не выбрасываете данные пользователей. Один из возможных вариантов - попытаться создать уникальный индекс. Если создание индекса не удается, сообщите им, что это не удалось, сообщите им, что им нужно исследовать, и предоставьте им сценарий, который они могут запустить, если обнаружат, что у них есть ошибка данных, которую они решили исправить.
Это решение, с которым я столкнулся в конце концов. Я проверяю, могу ли я добавить уникальный индекс. Если не могу, то откатываю базу данных и пытаюсь предоставить пользователю простые инструкции о том, как действовать. Не идеально, но, по крайней мере, целостность данных находится в руках пользователей ...
Я поддерживаю это решение. Использую для себя.