ROW_COUNT и execute statement

ЧАстые Вопросы и Ответы

Модераторы: kdv, CyberMax

Ответить
mdfv
Сообщения: 119
Зарегистрирован: 23 май 2006, 15:53

ROW_COUNT и execute statement

Сообщение mdfv » 19 фев 2007, 15:43

Есть ли возможность их подружить?
Или что можно стандартное и красивое взамен использовать?

Было в процедуре на select into сделано и ROW_COUNT работало,
потом пришлось переделать на execute statement into и ROW_COUNT перестал давать результат.

Dimitry Sibiryakov
Заслуженный разработчик
Сообщения: 1436
Зарегистрирован: 15 сен 2005, 09:05

Сообщение Dimitry Sibiryakov » 19 фев 2007, 15:48

Ну и слава темным магистрам. Хоть какая-то защита от... оптимистов..., сующих ЕС куда не стоит.
Но если хотите, FB - open source и его может фиксить каждый, кому не лень.

mdfv
Сообщения: 119
Зарегистрирован: 23 май 2006, 15:53

Сообщение mdfv » 19 фев 2007, 16:16

А чем всетаки радикально плох 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.
Или разработчики недоговорили чего-то страшного, известного узкому кругу лиц, активно искореняющему данное зло из неокрепших умов обывателей?

WildSery
Заслуженный разработчик
Сообщения: 1738
Зарегистрирован: 05 июн 2006, 16:19

Сообщение WildSery » 19 фев 2007, 16:58

mdfv писал(а):А чем всетаки радикально плох EXECUTE STATEMENT?
Ты Дмитрия не понял, тут шутка юмора в другом.
Почему-то выгоду и крайнюю необходимость (да и вообще хоть какую-то необходимость) в ES находят только новички, которые толком не умеют пользоваться хранимками и без использования ES, огребают кучу проблем а потом жалуются по всем форумам, что ничего не работает.
Вот у меня почему-то ни одного ES среди более чем 2000 процедур не понадобилось. Наверное, мы программируем неправильно? :wink:

ЗЫ: Раз уж ссылаешься на релиз-ноты, то там же и вычитай про область действия ROW_COUNT.

mdfv
Сообщения: 119
Зарегистрирован: 23 май 2006, 15:53

Сообщение mdfv » 19 фев 2007, 19:28

WildSery писал(а): Почему-то выгоду и крайнюю необходимость (да и вообще хоть какую-то необходимость) в ES находят только новички, которые толком не умеют пользоваться хранимками и без использования ES, огребают кучу проблем а потом жалуются по всем форумам, что ничего не работает.
Вот у меня почему-то ни одного ES среди более чем 2000 процедур не понадобилось. Наверное, мы программируем неправильно? :wink:
Я тоже так делаю, но мне не хочется плодить сотни процедур(в статических случаях я рефакторингом "нормализую" процедуры), если можно радикальнейшим образом уменьшить объем кода и сложность за счет ЕС и быстро решить достаточно сложную и объемную для обычной статичной ХП задачу.
Наверное у вас не возникает подозрений, если в клиентской части в DataSet.SelectSQL текст формируется динамически в зависимости от потребности в данный момент, а не плодится бессчетное их количество . Я конечно понимаю, что все хорошо в меру, и без очень веской надобности не использую.
Проблем с EC не было, одни удобства, все работает замечательно. (ROW_COUNT - это не проблема, а особенность :) )
Иногда такие монстры как вы :lol: напоминают моего начальника, который до сих пор думает старинными клипперовскими понятиями, и реляционная система и SQL не для него. Не надо постоянно отрицать разумное зерно, которое есть в каждой новой категории. Не обязательно перелезать высокую гору, когда есть короткий тоннель, пусть и опасный. Главное не забыть одеть каску и взять фонарик.
ЗЫ: Раз уж ссылаешься на релиз-ноты, то там же и вычитай про область действия ROW_COUNT.
Про то что он не работает с ЕС написано в 1.5.3, но и с селектами он только в 2 начал работать. Может когда-нибудь и до ЕС дойдет.

WildSery
Заслуженный разработчик
Сообщения: 1738
Зарегистрирован: 05 июн 2006, 16:19

Сообщение WildSery » 19 фев 2007, 21:29

Может сложность и уменьшит, а вот отладку такого кода...
Я не отрицаю, что есть задачи именно для ES. Только из действительно необходимых раз-два и обчёлся применений.
Фича порождена изначально как костыль для выполнения DDL в PSQL, и не стоит подпирать серьёзные задачи, если действительно только по-другому никак.

kdv
Forum Admin
Сообщения: 6595
Зарегистрирован: 25 окт 2004, 18:07

Сообщение kdv » 19 фев 2007, 22:46

Наверное у вас не возникает подозрений, если в клиентской части в DataSet.SelectSQL текст формируется динамически в зависимости от потребности в данный момент, а не плодится бессчетное их количество . Я конечно понимаю, что все хорошо в меру, и без очень веской надобности не использую.
динамическое формирование SQL на клиенте - это нормально. Но вот я сейчас прикидываю, что одна системка отчетов, которую я писал таким образом лет 6 назад, при реализации через ES превратилась бы в 3-4 раза большее количество кода. Причем клиентскую часть все равно надо было бы синхронизировать с вызовом такой замудренной процедуры.
А на клиенте там таблицы, столбцы и столбцы группировки-сортировки хранились в некоем подобии XML, поэтому отчет расширялся простым редактированием XML-а.

То есть, я не сторонник закидывания абсолютно всего на сервер, хотя в моей практике были и такие системы.

mdfv
Сообщения: 119
Зарегистрирован: 23 май 2006, 15:53

Сообщение mdfv » 20 фев 2007, 10:14

В моем случае задача поставлена в очень очень общем виде. А конкретные условия меняются очень часто и радикально. Я максимально перенес все что возможно на сервер. И клиентская часть является по сути только интерфейсной платформой с базовым функционалом и ее переделывать при изменениях не требуется.
И вся обработка и динамическое формирование смещено в серверную часть. И благодаря ЕС появилась возможность не затрагивая основное ядро легким движением производить чисто клиентские манипуляции.

Вот например:есть одна таблица с некоторым числом полянок, где содержатся суммы по категориям и некоторые полянки с флагами. Плюс дополнительные условия идентификации могут содержаться в любых других таблицах в зависимости от текущих потребностей.
При статическом связывании пришлось бы изменять часто и без того большие и сложные процедуры.
При использовании ЕС условия отбора и функции выбора сумм по категориям сложены в отдельной таблице уже в виде непосредственно SQL и заполняются стандартным способом на клиенте Админом базы(сейчас одна запись примерно в таком виде: sum(sumk1)+sum(sumk3)+sum(sumk10) и условие ((flag>10)and(flag<31)and(flag<>15)and(flag2 not in (select pole3 from table4 ))) потом можно будет сделать визуальный построитель с проверками). Эти условия могут быть абсолютно любыми. На сервере все это выбирается и складывается в текст ЕС и далее единым образом идет дальше. Конечно при такой вольности может быть куча ошибок и нестыковок, но в механизме выборки заложена жесткая многоуровневая проверка и ошибочные данные не пропускаются. И проблем с отладкой здесь нет.
А вообще я давно заметил, что если при проектировании программ меньше надеятся на всякие отладчики и проверочники, а изначально не лениться и тщательнее моделировать логику работы в голове, то и ошибок будет гораздо меньше.

Dimitry Sibiryakov
Заслуженный разработчик
Сообщения: 1436
Зарегистрирован: 15 сен 2005, 09:05

Сообщение Dimitry Sibiryakov » 20 фев 2007, 10:38

mdfv писал(а):условия отбора и функции выбора сумм по категориям сложены в отдельной таблице уже в виде непосредственно SQL и заполняются стандартным способом на клиенте Админом базы
Хорошо, тут ЕС, возможно, оправдан (хотя я в аналогичной ситуации выбирал этот запрос на клиента и (до-)формировал запрос там). Но в какое место этой схемы ты хочешь воткнуть ROW_COUNT?

mdfv
Сообщения: 119
Зарегистрирован: 23 май 2006, 15:53

Сообщение mdfv » 20 фев 2007, 11:40

Dimitry Sibiryakov писал(а):Хорошо, тут ЕС, возможно, оправдан (хотя я в аналогичной ситуации выбирал этот запрос на клиента и (до-)формировал запрос там).
Зачем выбирать на клиента, когда тоже самое может и сервер, и накладных расходов меньше и опять же тогда придется жестко в клиента зашивать основу, а так вызвал процедуру, которая что-то в себе делает и результат готов. И при надобности подкорректировать или радикально изменить логику работы, не нужно клиента переделывать. А потеряются исходники клиента вместе с автором :) и не страшно будет, т.к. архитектура открытая, модифицируемая, достаточно универсальная и расширяемая практически до бесконечности.
Но в какое место этой схемы ты хочешь воткнуть ROW_COUNT?
Ну к примеру после выполнения запроса, данных может не оказаться
и надо пропустить дальнейшую обработку.
Сейчас на null проверяю результаты, но с ROW_COUNT логически красивее было.

Dimitry Sibiryakov
Заслуженный разработчик
Сообщения: 1436
Зарегистрирован: 15 сен 2005, 09:05

Сообщение Dimitry Sibiryakov » 20 фев 2007, 12:34

mdfv писал(а):Ну к примеру после выполнения запроса, данных может не оказаться и надо пропустить дальнейшую обработку.
А что, FOR SELECT/EXECUTE STATEMENT использовать религия не позволяет?

mdfv
Сообщения: 119
Зарегистрирован: 23 май 2006, 15:53

Сообщение mdfv » 20 фев 2007, 14:11

А что, FOR SELECT/EXECUTE STATEMENT использовать религия не позволяет?
Использую пока только в многострочных запросах. А в одиночных плохо смотрится, потом будешь долго вспоминать зачем тут цикл поставил, когда его по логике вроде не должно быть. Вполне возможно излишнее предубеждение, но я стараюсь, чтобы код, кроме функциональности и быстродействия еще был самодокументируемым, удобочитаемым и удобоизменяемым, комментарии не всегда помогают быстро вспомнить, что здесь сделал даже месяц назад.

Ответить