У меня была эта проблема несколько раз, и я решил ее так же. Но это не красиво, и мне было интересно, знает ли кто-нибудь что-нибудь более элегантное ...
Основная цель:
- У меня есть фрагмент кода, общий для многих хранимых процедур.
- В целях обслуживания мне нравится модульность.
- Поэтому я хочу поместить этот общий код в собственную хранимую процедуру.
- Все остальные хранимые процедуры вызывают это.
- Привет заранее, модульный, многократно используемый, обслуживаемый код.
Сложная проблема:
- Общий код генерирует два набора записей / таблицы
- Сохраненный процесс или функция не может вернуть две таблицы в сохраненный процесс
- Создание двух таблиц в отдельных функциях значительно снизит производительность
(Это может привести к значительному избыточному пересчету)
Исторически используемые решения:
1> Создать таблицы #Temp во внешнем SP
- Центральный код вставляется в таблицы #temp
- Позволяет возвращать любое количество наборов данных
- Если к данным добавляются новые столбцы, каждый внешний SP также должен быть пересмотрен.
2> Создание реальных таблиц для вставки данных.
- Если к данным добавляются новые столбцы, нужно изменить только один набор определений таблиц.
- Требуется «идентификаторы сеанса», чтобы различать «мои данные» и данные других процессов.
- Из-за ошибок и т. Д. Старые данные могут остаться в таблице, что потребует еженедельной очистки.
- загромождает базу данных.
Первый вариант становится ближе к модульной цели. Логические изменения нужно проводить только в одном месте. Но дополнительные столбцы и т. Д. Требуют идентификации каждого бита кода, который использует SP, и обновления определений таблицы #temp.
Второй вариант делает это намного более элегантным, но вводит целый ряд новых соображений, которые снова убивают элегантность.
При использовании только SQL Server 2005, есть ли лучший вариант? (Работа в SQL Server 2000 также будет бонусом.)
Ура,
Mat.