Председатель Маоа теперь представьте
Уважаемый, Вы пожалуйста сначала покажите свое решение, потом будем разбираться с другими Вашими... веселыми представлениями.

SergSuperкстати вот пример недостатка оракловского null в строках по сравнению с ансишным
Да нет недостатка, просто я расписал этот фрагмент так, чтобы неоракловцы точно поняли, что имеется в виду. Реально там следовало бы использовать функцию nvl2 и результат был бы таким же, как у Вас.

Впрочем, это как раз наиболее неудачная особенность null-ов. Почему неудачная - приведу пример:


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

Yo.!!
Мне кажется, кто-то из нас двоих тормозит, и мне кажется, это не я.

Yo.!! imho nvl вполне хватает ?
Решение с nvl, которое я вижу, нравится мне меньше, чем использование nvl2.

Председатель Маоа что в оракле нет isnull()?
Cкорее всего нет. Нафиг ему плохо названная нестандартная функция? В стандарте есть coalesce, которая удобнее и ораклового nvl, и mssql-ного isnull. На текущий момент я рекомендую своим использовать в коде именно coalesce.

Председатель МаоЕсли это так, то такое же можно сделать в MSSQL
Ну так сделайте, пожалуйста. Покажите код и результаты, полный скрипт, который любой может выполнить и увидеть. Напоминаю:

1. Есть два пользователя, t_app и t_user (или как угодно еще названные)
2. У пользователя t_app есть таблица
3. У пользователя t_app есть процедура, получающая строку фильтра и возвращающую выборку из таблицы, отфильтрованную указанным выражением
4. Пользователь t_user может вызвать процедуру и увидеть результаты
5. Пользователю t_user недоступен прямой select к таблице

Председатель МаоДопустим у вас есть 6000 записей, вам нужно их вернуть. При селекте это будет одна итерация к серверу с 6000 строками, а при курсоре 6000 итераций по одной записи. Улавливаете разницу. Это конечно очень натянуто, но суть я думаю ясна.
Конечно, улавливаем. Допустим, мы хотим вывести эти данные в грид, показать пользователю. Вашей программе придется ждать, пока с сервера приедут все 6000 (или 60000. или 600000) записей. Моя запросит первые сто строк, покажет первые двадцать пять, и если пользователь не будет особо нажимать PgDn, оставшиеся никогда у сервера и не попросит. Если же мне потребуются все строки, например чтобы построить по ним какую-нибудь хитрую графику, я установлю FetchSize в миллион и опять же получу их "за одну итерацию".

SergSuperХотя интересно посмотреть как это выглядит с nvl2 и nvl


SergSuperЕсли поле не допускает нулов - то будет ошибка.
Если не допускает, то будет ошибка. А если допускает?

SergSuperМне кажется наоборот удобно когда есть некая отдельная сущность.
А на самом деле это больше дело привычки.
Null как отдельная сущность - очень хорошая вещь. Это не дело привычки, поверьте, это дело соответствия инструмента задачам. Я работал над проектом, где было принято неиспользование null-ов, и насмотрелся на вытекающие из этого проблемы и ошибки, которые люди делали и делали несмотря на привычку.

Я целиком за null как отдельную сущность, но данную конкретную деталь его определения - "большинство операций с null дает результатом null" - я бы сделал иначе.

Мимопроходящийкак именно иначе?
Операции, в которых может участвовать null, можно разбить на три группы:

- те, в которых его участие осмысленно (is null, =, ||)
- те, в которых его участие [почти всегда] бессмысленно (скажем, арифметика)
- те, в которых вообще говоря бессмысленно, но сложно отфильтровать (скажем, агрегатные функции)

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

Так вот, первую и третью группы я бы оставил работать как сейчас, а во второй аргумент null считал бы ошибкой. Разумеется, все это строится на предположении о существовании "бессмысленных" операций. А это предположение - на том, что с ситуацией, где арифметика с участием null осмысленна, я не сталкивался.

Председатель Мао
Ээ.... я бы отметил, что в постановке задачи говорится о фильтрации произвольным выражением, а не о передаче маски для конкретного поля.

Если говорить о задаче в том объеме, который сделали Вы, мне кажется можно обойтись без промежуточной таблицы, возвращая статическую выборку - например, используя like по переданному значению.

Но я бы отметил именно тот факт, что в MSSQL при полноценном решении придется делать так, как делаете Вы - сначала динамическим sql с собственными правами наполнить временную таблицу, а потом статическим sql вернуть ее наружу. Эффективность этой конструкции.... не впечатляет, имхо.

ChAПосылать - дело нехитрое
Хм.

ChA Но что-то мне подсказывает
Это "что-то" - то же, что подсказывало ее невозможность?

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

Сколь я помню ту статью, никакого дополнительного геморроя при этом нет. Cерверная процедура остается неизменной, в ODBC результат возвращается так же, как вернулся бы из аналогичной MSSQL-процедуры и выбирается тем же клиентским кодом.

ChAХмм, степень оправданности - вещь достаточно субъективная.
В общем случае - да. Тем не менее, зависимость интерфейса от реализации - повсеместно считается неоправданной.

ChAПолагаю в Oracle тоже найдутся подобные казусы, но мы о них разумеется, говорить не будем.
Наверное, найдутся. Говорите, с интересом послушаю. Вон, председатель тоже был уверен в наличии казуса.

ChAНу это всего лишь Ваше мнение, да и слухи о его смерти сильно преувеличены.
Ну, "мнение" таки весомее "отмазок". Слухи же Вы легко можете развеять, если приведете внушительный список распространенного прикладного ПО, использующего ODBC как единственный либо основной интерфейс взаимодействия с БД.

Могу даже ограничить задачу: список ПО авторства Microsoft, использующего ODBC как единственный либо основной интерфейс.

Относительно ПО авторства Oracle и OCI - поверите на слово, что приведу такой список?

ChAIMHO, наличие любого общепринятого стандарта лучше, чем его отсутствие.
Общепринятых стандартов в RDBMS нет. Что же до стандартов вообще - наличие хороших стандартов хорошо, наличие плохих стандартов плохо. Отсутствие стандартов - посередине.

ChAВпрочем, знаком с Вашим пренебрежением к любым стандартам, включая законы ;) Хорошо, что это ограничивается только словами.
Поверхностное знакомство диктует поверхностные выводы.

ChAА курсоры и в MSSQL можно передавать из вызываемой процедуры в вызывающую процедуру
Стоп. Курсоры или рекордсеты? Поясню: в описанном механизме Oracle я могу один и тот же курсор и использовать на сервере, и передать на клиента. То есть если есть хранимка, возвращающая выборку, я могу использовать эту выборку и на сервере, и на клиенте. Сколь я понимаю в MSSQL, тот явный курсор, который можно передать, и тот неявный рекордсет, который едет на клиента - разные вещи, "одной процедуры для обоих применений" сделать не удастся. Или я заблуждаюсь?

ChAто с какого лешего Вы ждете ответа от меня ?
А кто Вам сказал, что я жду ответа от Вас? Эта фраза - часть резюме по сравнению.