ROW_COUNT и execute statement
ROW_COUNT и execute statement
Есть ли возможность их подружить?
Или что можно стандартное и красивое взамен использовать?
Было в процедуре на select into сделано и ROW_COUNT работало,
потом пришлось переделать на execute statement into и ROW_COUNT перестал давать результат.
Или что можно стандартное и красивое взамен использовать?
Было в процедуре на select into сделано и ROW_COUNT работало,
потом пришлось переделать на execute statement into и ROW_COUNT перестал давать результат.
-
- Заслуженный разработчик
- Сообщения: 1436
- Зарегистрирован: 15 сен 2005, 09:05
А чем всетаки радикально плох EXECUTE STATEMENT?
При осторожном использовании весьма значительная выгода присутствует.
Ничего особо криминального в этом тексте не нашел:
При осторожном использовании весьма значительная выгода присутствует.
Ничего особо криминального в этом тексте не нашел:
Или разработчики недоговорили чего-то страшного, известного узкому кругу лиц, активно искореняющему данное зло из неокрепших умов обывателей?EXECUTE STATEMENT is potentially unsafe in several ways:
1. There is no way to validate the syntax of the enclosed statement.
2. There are no dependency checks to discover whether tables or columns have been dropped.
3. Operations will be slow because the embedded statement has to be prepared every time it is
executed.
4. Return values are strictly checked for data type in order to avoid unpredictable type-casting
exceptions. For example, the string ’1234’ would convert to an integer, 1234, but ’abc’ would give
a conversion error.
5. If the stored procedure has special privileges on some objects, the dynamic statement submitted in
the EXECUTE STATEMENT string does not inherit them. Privileges are restricted to those granted to
the user who is executing the procedure.
Ты Дмитрия не понял, тут шутка юмора в другом.mdfv писал(а):А чем всетаки радикально плох EXECUTE STATEMENT?
Почему-то выгоду и крайнюю необходимость (да и вообще хоть какую-то необходимость) в ES находят только новички, которые толком не умеют пользоваться хранимками и без использования ES, огребают кучу проблем а потом жалуются по всем форумам, что ничего не работает.
Вот у меня почему-то ни одного ES среди более чем 2000 процедур не понадобилось. Наверное, мы программируем неправильно?
ЗЫ: Раз уж ссылаешься на релиз-ноты, то там же и вычитай про область действия ROW_COUNT.
Я тоже так делаю, но мне не хочется плодить сотни процедур(в статических случаях я рефакторингом "нормализую" процедуры), если можно радикальнейшим образом уменьшить объем кода и сложность за счет ЕС и быстро решить достаточно сложную и объемную для обычной статичной ХП задачу.WildSery писал(а): Почему-то выгоду и крайнюю необходимость (да и вообще хоть какую-то необходимость) в ES находят только новички, которые толком не умеют пользоваться хранимками и без использования ES, огребают кучу проблем а потом жалуются по всем форумам, что ничего не работает.
Вот у меня почему-то ни одного ES среди более чем 2000 процедур не понадобилось. Наверное, мы программируем неправильно?
Наверное у вас не возникает подозрений, если в клиентской части в DataSet.SelectSQL текст формируется динамически в зависимости от потребности в данный момент, а не плодится бессчетное их количество . Я конечно понимаю, что все хорошо в меру, и без очень веской надобности не использую.
Проблем с EC не было, одни удобства, все работает замечательно. (ROW_COUNT - это не проблема, а особенность )
Иногда такие монстры как вы напоминают моего начальника, который до сих пор думает старинными клипперовскими понятиями, и реляционная система и SQL не для него. Не надо постоянно отрицать разумное зерно, которое есть в каждой новой категории. Не обязательно перелезать высокую гору, когда есть короткий тоннель, пусть и опасный. Главное не забыть одеть каску и взять фонарик.
Про то что он не работает с ЕС написано в 1.5.3, но и с селектами он только в 2 начал работать. Может когда-нибудь и до ЕС дойдет.ЗЫ: Раз уж ссылаешься на релиз-ноты, то там же и вычитай про область действия ROW_COUNT.
Может сложность и уменьшит, а вот отладку такого кода...
Я не отрицаю, что есть задачи именно для ES. Только из действительно необходимых раз-два и обчёлся применений.
Фича порождена изначально как костыль для выполнения DDL в PSQL, и не стоит подпирать серьёзные задачи, если действительно только по-другому никак.
Я не отрицаю, что есть задачи именно для ES. Только из действительно необходимых раз-два и обчёлся применений.
Фича порождена изначально как костыль для выполнения DDL в PSQL, и не стоит подпирать серьёзные задачи, если действительно только по-другому никак.
динамическое формирование SQL на клиенте - это нормально. Но вот я сейчас прикидываю, что одна системка отчетов, которую я писал таким образом лет 6 назад, при реализации через ES превратилась бы в 3-4 раза большее количество кода. Причем клиентскую часть все равно надо было бы синхронизировать с вызовом такой замудренной процедуры.Наверное у вас не возникает подозрений, если в клиентской части в DataSet.SelectSQL текст формируется динамически в зависимости от потребности в данный момент, а не плодится бессчетное их количество . Я конечно понимаю, что все хорошо в меру, и без очень веской надобности не использую.
А на клиенте там таблицы, столбцы и столбцы группировки-сортировки хранились в некоем подобии XML, поэтому отчет расширялся простым редактированием XML-а.
То есть, я не сторонник закидывания абсолютно всего на сервер, хотя в моей практике были и такие системы.
В моем случае задача поставлена в очень очень общем виде. А конкретные условия меняются очень часто и радикально. Я максимально перенес все что возможно на сервер. И клиентская часть является по сути только интерфейсной платформой с базовым функционалом и ее переделывать при изменениях не требуется.
И вся обработка и динамическое формирование смещено в серверную часть. И благодаря ЕС появилась возможность не затрагивая основное ядро легким движением производить чисто клиентские манипуляции.
Вот например:есть одна таблица с некоторым числом полянок, где содержатся суммы по категориям и некоторые полянки с флагами. Плюс дополнительные условия идентификации могут содержаться в любых других таблицах в зависимости от текущих потребностей.
При статическом связывании пришлось бы изменять часто и без того большие и сложные процедуры.
При использовании ЕС условия отбора и функции выбора сумм по категориям сложены в отдельной таблице уже в виде непосредственно SQL и заполняются стандартным способом на клиенте Админом базы(сейчас одна запись примерно в таком виде: sum(sumk1)+sum(sumk3)+sum(sumk10) и условие ((flag>10)and(flag<31)and(flag<>15)and(flag2 not in (select pole3 from table4 ))) потом можно будет сделать визуальный построитель с проверками). Эти условия могут быть абсолютно любыми. На сервере все это выбирается и складывается в текст ЕС и далее единым образом идет дальше. Конечно при такой вольности может быть куча ошибок и нестыковок, но в механизме выборки заложена жесткая многоуровневая проверка и ошибочные данные не пропускаются. И проблем с отладкой здесь нет.
А вообще я давно заметил, что если при проектировании программ меньше надеятся на всякие отладчики и проверочники, а изначально не лениться и тщательнее моделировать логику работы в голове, то и ошибок будет гораздо меньше.
И вся обработка и динамическое формирование смещено в серверную часть. И благодаря ЕС появилась возможность не затрагивая основное ядро легким движением производить чисто клиентские манипуляции.
Вот например:есть одна таблица с некоторым числом полянок, где содержатся суммы по категориям и некоторые полянки с флагами. Плюс дополнительные условия идентификации могут содержаться в любых других таблицах в зависимости от текущих потребностей.
При статическом связывании пришлось бы изменять часто и без того большие и сложные процедуры.
При использовании ЕС условия отбора и функции выбора сумм по категориям сложены в отдельной таблице уже в виде непосредственно SQL и заполняются стандартным способом на клиенте Админом базы(сейчас одна запись примерно в таком виде: sum(sumk1)+sum(sumk3)+sum(sumk10) и условие ((flag>10)and(flag<31)and(flag<>15)and(flag2 not in (select pole3 from table4 ))) потом можно будет сделать визуальный построитель с проверками). Эти условия могут быть абсолютно любыми. На сервере все это выбирается и складывается в текст ЕС и далее единым образом идет дальше. Конечно при такой вольности может быть куча ошибок и нестыковок, но в механизме выборки заложена жесткая многоуровневая проверка и ошибочные данные не пропускаются. И проблем с отладкой здесь нет.
А вообще я давно заметил, что если при проектировании программ меньше надеятся на всякие отладчики и проверочники, а изначально не лениться и тщательнее моделировать логику работы в голове, то и ошибок будет гораздо меньше.
-
- Заслуженный разработчик
- Сообщения: 1436
- Зарегистрирован: 15 сен 2005, 09:05
Хорошо, тут ЕС, возможно, оправдан (хотя я в аналогичной ситуации выбирал этот запрос на клиента и (до-)формировал запрос там). Но в какое место этой схемы ты хочешь воткнуть ROW_COUNT?mdfv писал(а):условия отбора и функции выбора сумм по категориям сложены в отдельной таблице уже в виде непосредственно SQL и заполняются стандартным способом на клиенте Админом базы
Зачем выбирать на клиента, когда тоже самое может и сервер, и накладных расходов меньше и опять же тогда придется жестко в клиента зашивать основу, а так вызвал процедуру, которая что-то в себе делает и результат готов. И при надобности подкорректировать или радикально изменить логику работы, не нужно клиента переделывать. А потеряются исходники клиента вместе с автором и не страшно будет, т.к. архитектура открытая, модифицируемая, достаточно универсальная и расширяемая практически до бесконечности.Dimitry Sibiryakov писал(а):Хорошо, тут ЕС, возможно, оправдан (хотя я в аналогичной ситуации выбирал этот запрос на клиента и (до-)формировал запрос там).
Ну к примеру после выполнения запроса, данных может не оказатьсяНо в какое место этой схемы ты хочешь воткнуть ROW_COUNT?
и надо пропустить дальнейшую обработку.
Сейчас на null проверяю результаты, но с ROW_COUNT логически красивее было.
-
- Заслуженный разработчик
- Сообщения: 1436
- Зарегистрирован: 15 сен 2005, 09:05
Использую пока только в многострочных запросах. А в одиночных плохо смотрится, потом будешь долго вспоминать зачем тут цикл поставил, когда его по логике вроде не должно быть. Вполне возможно излишнее предубеждение, но я стараюсь, чтобы код, кроме функциональности и быстродействия еще был самодокументируемым, удобочитаемым и удобоизменяемым, комментарии не всегда помогают быстро вспомнить, что здесь сделал даже месяц назад.А что, FOR SELECT/EXECUTE STATEMENT использовать религия не позволяет?