Коллеги, добрый день!

В хранимой процедуре необходимо понимать, какие параметры не были переданы, а каким параметрам передано значение NULL (т.е. определить смысл значения NULL). Это необходимо для реализации логики обновления полей (если не передано значение - не трогаем, передано - обновляем). У кого-нибудь есть пример шаблона хранимой процедуры для решения данной задачи?

Вижу 2 варианта.
1) Ввести входной параметр маски реально переданных параметров (т.е. вызывающая сторона уточняет перечень передаваемых параметров);
2) Определить специальные значения входных параметров, которые будут указывать, что передано пустое значение (т.е. default значение null означает отсутствие передачи параметра, а пустая строка, например для varchar, означает необходимость сбросить значение поля в БД в NULL).

Спасибо)

Guf,
авторВариант 3. Не выворачивать мозги. Передавать всегда и всё и обновлять тем, что передано.
Есть сущности, содержащие более 100 столбцов. Объявлять овер 100 переменных и начитывать их перед EXEC - ну такое себе.
И, часто, надо обновить лишь небольшую часть столбцов. Понятно, что бизнес-логика должна быть разбита по разным ХП, но не всегда и не везде это получается. Прямые UPDATE на таблицу не рассматриваются, т.к. пролетают мимо важных контролей внутри ХП.

Это работает до тех пор, пока вам не надо "пропихнуть" NULL как реальное значение. Т.е. вы никогда не сможете обnullить значение в БД.

Всем спасибо за мнения! Динамический SQL явно мимо; финальные контроли осуществляются на сервере. Может изначально плохо пояснил задачу. Смысл в том, что есть много входных точек для изменения данных (api), реализующих разные форматы и разный набор полей. Соответственно вопрос был в обновлении информации в базе данных (после приема входящего запроса).
Пока остановились на следующем варианте:



Хотя итоговое решение не понравилось (вызов такой ХП выглядит "неестественным"). Пока будет использоваться исключительно локально (для решения конкретной задачи). Возможно, часть контролей будет перенесена + прямой UPDATE таблицы + прочая логика процедуры usp_update.

felix_ff,

Да, в базовой процедуре update 100+ параметров, значит придется и в обертке объявить 100+ параметров и поставить 100+ case. Сейчас без обертки то не лучше - начитай недостающие 100 параметров c case из таблицы и потом сделай EXEC базовой процедуры. Тут же не стоит вопрос уменьшения кода (хотя этот вариант в любом случае короче), вопрос скорее в понятности и дальнейшей поддержке. Например, в базовую процедуру достаточно часто вводятся новые параметры.




При таком вызове да. Но я же буду вызывать обертку и значение сохранится:



А при передачи @val2 = '' значение будет сброшено в null.

alexeyvg,

авторОй, а сначала сказали, что так точно не подходит :-)Нет, я такое не писал, Вы меня с кем-то перепутали =) Я сразу озвучил эту идею под вторым вариантом.
И в серверной части итак хватает старого легаси-кода, в основном связанного с динамическим sql))) Хламить не хочется, даже для решения небольшой задачи.

авторТак и делайте несколько входных точек (api).
Вы хотите сделать одну входную точку для всего приложения? Поверьте, нехорошо получитсяНет. Немного love story.
Есть базовая процедура для изменения сущности БД (usp_update в примере выше). На вход принимается полный перечень параметров и записывается в БД "как есть". При этом в процедуре реализуется прочая логика по проверкам, записи в логи и пр. Основная система в основном и дергает данную процедуру, т.к. почти всегда обладает информацией о полном состоянии объекта.
Однако есть и другие точки входа (различные api) для коррекции информации (включая xml/json форматы). Там перечень параметров гораздо уже. Общий подход следующий:
- если параметр не определен форматом, то оставляем текущее значение БД;
- если значение параметра/тега указано, то записываем в БД (включая пустое значение => NULL);
- если параметр/тег отсутствует, то оставляем текущее значение БД.
И проблема как раз в том, что код в этих точках входа (api) уже весьма сложный и неочевидный, с большими свистоплясками, чтобы вызвать базовую процедуру или выполнить прямой UPDATE. В первом случае это начитка большого числа параметров (текущее состояние в БД), а во втором это вынесенные контроли + запись в логи и пр. логика (хотя сам UPDATE таблицы смотрится конечно максимально читабельно). Делать свой вариант usp_update под каждый API выглядит трудозатратным (тем более там небольшая разница от api к api). Какая-нибудь обертка поверх базовой usp_update, которую можно было бы дергать из каждой точки входа (api), значительно бы упростила логику. Вопрос открыт :-)

invm,

Спасибо за мысль. XML собирать в некоторых случаях может быть чуть труднее, но безусловно логика процедуры становится более прозрачной. На самом деле в некоторые точки (api) на вход и прилетают такие xml :)