pt12ptЧто здесь проктологического?
Много всего:

Наличие у хранимых процедур необъявленных входных и выходных параметров

Наличие у хранимых процедур плохо контролируемых побочных эффектов

Передача важнейшей информации через неструктурированную глобальную переменную, аналог фортрановских "общих областей" (это такое достижение технологии 1957-го года, убрано из языка как устаревшее и неадекватное кажется в 1977-м)

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

pt12ptВ Оракле же мало того, что используется специальный язык,


pt12ptну бог с ним вам необходимо объявить курсорную переменную, заполнить ее данными и вернуть
В любом нормальном языке программирования процедура, желающая вернуть пользователю данные, должна иметь выходной параметр и должна вычислить его значение. Например, в Java, если Вы ходите посчитать количество элементов в списке, Вы пишете:




по аналогии, когда Вы в PL/SQL хотите посчитать количество строк в таблице, Вы пишете




Конечно, можно пытаться назвать это проктологией, но тогда придётся чохом занести в это понятие практически все языки программирования, разработанные начиная с 60-х годов. По мне всё же "извращенцев" стоит искать среди желающих возвращать результаты работы каким-то другим способом.

lockyа насчет "противоречащий стандарту" - главное чтобы не противоречило здравому смыслу и потребностям, остальное - от лукавого.
Согласен. Собственно моё большое удивление по поводу unique в mssql вызвано именно его категорическим противоречием здравому смыслу. Стандарт же я здесь упомянул только для подчёркивания противопоставления "документированному поведению". Там, где стандарт противоречит здравому смыслу (например, в требовании различать null и пустую строку) я сам с большим удовольствием поддерживаю забивание на стандарт.

lockyкак по мне, так лучше иметь 2 (или более) способа выполнить некую задачу,
Способы различаются удобством, опасностью, полезностью в некоторых специфических ситуациях. Я в целом "за" способы, которые хоть в каких-то реальных ситуациях заметно лучше других. Что же касается конкретно этого... на решающую суперфичу он, деликатно говоря, ну никак не тянет.

lockyнежели с пеной у рта доказывать всем и каждому "есть только один исконно правильный способ, нужно использовать его! Ведь по другому то и не сделаешь!"
Тем не менее я рад, что многие выдающиеся учёные с пеной у рта доказали таки всем и каждому, что надо выкинуть из языков программирования такие способы выполнить задачу, как операторы ALTER PERFORM и ASSIGNABLE GOTO, альтернативные точки входа в функции, COMMON области, GOTO в тело другой подпрограммы и целый ряд прочих подобных фич.

pkarklinВот здесь можно прочитать о новой опции EXECUTE - WITH <result_sets_definition>. Приведу только пример:
Если я правильно понял, то это косметическое изменение, от которого я не ждал бы большого эффекта. В лучшем случае оно улучшит диагностику проблемных ситуаций "когда всё уже упало" - вместо невнятного падения ХП в случайном месте со случайной диагностикой будет падение с диагностикой "кривые входные резалтсеты". Но более важно то, что если ХП вызывается из двадцати мест, то это требует писать одно и то же в двадцати местах?

lockyНо, тем не менее, UQ с множественными NULL значениями - в скуле таки есть, реализуемы.
Безусловно. Напоминаю Вам, что я здесь не нападаю на MSSQL, а всего лишь дезавуирую аргумент "документировано - значит правильно", выдвинутый Павлом. Мог бы, конечно, дезавуировать на примере документированных оракловых нуллов - но по мне это было бы демагогией.

pkarklinЯ могу в Oracle написать такую функцию (утрировано):



Если я правильно понял, что Вы хотите, то это пишется так:




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

lockyЧто интересно, ораклоиды крайне редко приводят в качестве примеров того, что у них есть хорошего
В свете специфики типичного "сравнения" это неудивительно. Меня удивляет как раз то, что мссклщики козыряют фигнёй вместо тех немногих вещей, которые у них действительно лучше (ну дисклеймер - немногих, которые я знаю. может, многих хороших не знаю).

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

pkarklinТак можно договорится до того, что в Pascal надо было не допускать использования writeln в процедурах и функциях, ибо непонятно, куда же информация передается из процедуры.
Ну если человек перенаправит stdout и построит взаимодействие внутри приложения по принципу "одна процедура пишет writeln-ами, другая читал readln-ами", я пожалуй таки уверенно назову его нестандартно ориентированным. Что же до Pascal, то writeln из него надо было выкинуть ещё в середине девяностых, равно как и сейчас наблюдается ну просто волшебная корреляция между флагом "говнокод" и наличием в тексте всяких system.out.println.

lockyДа нам это как-то и не надо, козырять то :)
К сожалению, практика не подтверждает истинность Ваших слов. Если очень не лень, сделайте поиск по форуму - несколько лет назад я делал глобальную выборку "холиварных" топиков форума на предмет "кто их начал: ораклоид/мссклщик/неизвестно". В итоге примерно 100% топиков были начаты мссклщиком с общим девизом "почему все кричат про крутоту оракла, когда у нас не хуже".

lockyКак правило, стандартных ответов всего два:
Правильно. Обратите внимание: ответов. А ответов на что?

lockysoftwarerПравильно. Обратите внимание: ответов. А ответов на что?
На любой аргумент.
Ну собственно про "кому надо козырять" вроде как уже очевидно.