Изменения версии для Хранимых процедур

Я бы воспользовался этой возможностью, чтобы перейти от хранимых процедур к ORM или другому подходу. Оба предложенных вами решения потребуют некоторого изменения кода, чтобы решить, какую хранимую процедуру использовать. Вместо этого я бы решил, использовать ли хранимые процедуры или ORM. Я бы также составил планы по поэтапному отказу от большинства хранимых процедур.

За свою карьеру я видел много плохого кода и испорченных систем, но ничто не разбивает мои надежды на то, что проект можно спасти, как если бы я видел GetItemFromLots_2_Temp_2 в списке хранимых процедур. Множественные методы намного красивее и проще в обслуживании, чем множественные хранимые процедуры.

(Для тех, кто любит хранимые процедуры. Я не говорю, что они плохие. Я »

Измените существующие хранимые процедуры так, чтобы новая логика выполнялась условно, только когда процедура вызывается в тех случаях, когда новая логика должна получить выполнено ... Если новый процесс будет иметь немного другой интерфейс (набор параметров sProc), вы можете сделать их необязательными и использовать наличие или отсутствие параметра как переключатель для управления тем, какой фрагмент кода будет выполняться в процессе .. .

Когда старая логика больше не нужна, вы можете просто удалить ее из sProcs

Я бы не стал создавать два разных файла, это точно.

Может быть, в системе управления версиями вы должны создать ветвь всех ваших версий, а затем новую ветку с вашей следующей версии, то вы можете включить обе ветки в качестве отдельных папок в вашу систему, и ваша бизнес-логика будет указывать на нужное место.

Это решение может быть немного небрежным, но я думаю, что это меньшее из нескольких зол.

Как бы то ни было, на самом деле, на мой взгляд, абсолютно необходимо контролировать версии кода хранимой процедуры.

Я бы предложил второй вариант, который вы предоставили. Используйте параметр версии. Это то, что делают веб-службы, чтобы они не нарушали код приложений, которые начали использовать API давно, но API в какой-то момент обновляется.

Бьюсь об заклад, есть некоторая одинаковая логика между двумя версии, которые вы могли бы абстрагировать в нижней части процедуры или что-то в этом роде. Или, возможно, создайте функции для общих элементов и вызовите эти функции в ваших больших блоках IF / SWTICH.

Раньше мы широко использовали хранимые процедуры в моей компании, но в последнее время (в основном) перешли от них к ORM.

Мы все еще используем их, и наше управление версиями такое же как это было раньше: каждый раз, когда мы изменяем оставшиеся хранимые процедуры (на что имеют право лишь немногие люди), мы сохраняем SQL и сохраняем файл .sql в нашем контроле версий.

Он несовершенен, и мы теряют большую часть интеграции между системой управления версиями и нашими файлами кода (поскольку нет интеграции SQL-сервера с TFS), но это лучше, чем полное отсутствие системы управления версиями.

РЕДАКТИРОВАТЬ - и, конечно, это работает, только если вы больше не нужно использовать старую версию сохраненной процедуры, поскольку она больше не будет существовать в работающей форме.

Еще один интересный подход - хранить весь код ваших хранимых процедур в таблице базы данных вместе с версией кода. Затем у вас есть «внешний процесс», который обрабатывает запросы, а затем, в зависимости от версии, динамически создает процесс и выполняет его. После этого процесс может быть прерван.

Обычное предложение, но оно может сработать для вас.

Я бы выбрал вариант с двумя файлами по следующим двум причинам:

• Подпись, то есть количество параметров, которое может изменяться между версиями
• Каждая хранимая процедура будет проще, следовательно, меньше вероятность ошибок из-за всего условного кода