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

Question

У меня есть приложение, которое очень сильно зависит от хранимых процедур (SQL 2005/2008). Мы делаем небольшое обновление, которое изменит 25-35 этих хранимых процедур. Приложение таково, что обе версии хранимой процедуры должны быть доступны.

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

Вот мои 2 варианта, которые я придумала

1. Создайте «2» версию каждой хранимой процедуры. Если бы у меня была процедура getUser, создайте getUser2. Недостатком этого является то, что количество хранимых процедур будет расти экспоненциально с каждым изменением версии

2. Добавьте параметр @version к каждой хранимой процедуре, по умолчанию v1. Это уменьшит количество хранимых процедур, но увеличит число хранимых процедур

У кого-нибудь есть мысли по этому поводу? Любые другие умные идеи?

Cody

Answer 1

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

Я видел много плохого кода и испортил системы в моей карьере, но ничто не лишает меня надежды на то, что проект можно спасти, как если бы он увидел GetItemFromLots_2_Temp_2 в списке хранимых процедур. Несколько методов намного красивее и проще в обслуживании, чем несколько хранимых процедур.

(Для тех, кто любит хранимые процедуры. Я не говорю, что они плохие. Я уверен, что есть хитрые подходы к обработке такого рода вещей с использованием хранимых процедур, но, если такой подход использовался, этот вопрос не спросили бы.)

Answer 2

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

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

Answer 3

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

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

Answer 4

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

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

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

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

Answer 5

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

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

Answer 6

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

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

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

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

Answer 7

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

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