«Непонятные люди требуют странного» ©

Вроде бы очевидный синтаксис не поддерживается:


Довольно часто встречается ситуация, когда в детальной таблице обязательно нужна хотя бы одна запись для каждой из мастера.
Конечно, можно выполнить эти 2 insert -а на клиенте, в execute block или SP.
Но ведь так более явно короче и понятнее. :)

Почему бы не научить сервер понимать подобный синтаксис?

Симонов Дениссмысла в такой конструкции будет мало, потому как детальной таблице обычно больше одной записи
Ну, это тоже зависит от многого.
Я частенько встречаюсь с табличками где деталей < 1,5 на мастер...
Кроме того, ежели заменить insert into MASTER ... на update or insert into MASTER то можно будет все детали вставлять подобным образом.
Особливо ежели запилить в update or insert синтаксис позволяющий не только устанавливать поля в константы, но и изменять их значения на основе предыдущих, типа как set fld1 = fld1 + 1 в update .

Опять же, подобного поведения можно добиться несколькими путями - например триггерами на insert и update в изменяемой вьюхе.
Но в этом случае будет компактнее. :)

Ещё открывающиеся возможности:
Удаление с записью в журнал:



Изменение с записью в журнал:


И много других извращений. :)

Dimitry Sibiryakov[Открой для себя триггера. В отличии от твоих извращений, они работают вне зависимости от
настроения левой пятки программиста приложения.

Э... А как триггера защищены от "настроения левой пятки программиста"?
Да и мёртвый цикл запилить что на триггерах что на SP тоже не велика сложность. :)

Dimitry Sibiryakov,
А триггера видимо пишет кто-то непогрешимый? :)

miwaonline,
Ну по задаче там идеально подошла бы изменяемая въюха с триггером на инсерт.
Но задача - единоразовый импорт.
Далее, по логике основной задачи, когда данные уже заполнены, эта въюха попросту не нужна.
Там даже триггера особо не нужны кроме стандартных автоинкрементных. Ну и каскадного удаления...

И вместо того, чтобы нарисовать один, пусть сложный, запрос, предлагается запилить въюху с триггерами?

miwaonlineНарисуй один (не)сложный execute block.
Собственно с этого я и начал, что вместо "(не)сложный execute block " можно было бы нарисовать ещё более несложный каскадный insert .
И этот каскадный insert даже более защищён от ошибок чем execute block , хотя бы потому что текста меньше. :)

Секретное имя пользователяиз-за того, что тебе лень пилить взгляд (вьюху), ты хочешь напрячь разработчиков, чтобы они расхерачили сервер твоими хотелками ?
Мне не лень "пилить вьюху" - она там совершенно не нужна.
И естественно сервер расхерачивать не нужно.

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

miwaonlineНапример - а какова глубина вложенности должна поддерживаться у каскадных inserto-ов? А почему только 2/10/100/1000? А вдруг я хочу сделать удобный лично мне супер-мега-динамический insert где значение последующего элемента вычисляется на основании предыдущего значения?
Это всяко определять разработчикам. :)
Но мнится мне, что никак не больше текущего ограничения на количество контекстов - вроде кардинального отличия от вложенных select -ов в этом разрезе не видно...

Симонов Денис

и при недофетченности курсора получаем мутный результат
Вроде как мои предложения лишены этого недостатка.
Т. е. returning остаётся как есть но может выступать и как отдельное значение.

Конечно в этом случае можно изобразить что-то в таком роде:


В результате чего можно получить тот же мутный результат при недофетченности курсора.
Но того же можно добиться и execite block -ом, да и SP, и это вроде никого не пугает.
А новичкам быстро объясняют про грабли недофетченного курсора + изменяющие SP или execite block .