#sql #postgresql
#sql #postgresql
Вопрос:
Я работаю над отчетом jasper.У меня есть таблица с именем user
I have 2 parameters internal
, external
.Когда я использую internal, тогда мой запрос должен показывать пользователям, где username LIKE '%_@__%.__%'
и когда я использую external, тогда мой запрос должен показывать пользователям, где username NOT LIKE '%_@__%.__%'
.Например, когда internal
в отчете будет отображаться 2,3,4,5 без строки, а когда external
в отчете будет отображаться только одна row..My запрос является
SELECT case
when $P{internal} = 'internal' then
id end as cid,
designation,division_name,pin_no,username FROM application_user where username LIKE
'%_@__%.__%'
else
id end as cid,
designation,division_name,pin_no,username FROM application_user where username NOT LIKE
'%_@__%.__%'
Пожалуйста, дайте мне знать, если я не понимаю
Комментарии:
1. Отправленный вами SQL недопустим: у вас есть
ELSE
без родительскогоWHEN
илиIF
.CASE WHEN
Оператор в строке 1 завершаетсяEND
в строке 4.2. тогда как я должен написать
3. Пожалуйста, отправьте данные в виде текста, а не в виде изображения.
4. хорошо … я буду поддерживать его с этого момента
Ответ №1:
Операторы проекции не могут быть параметризованы в SQL напрямую (но вы можете в динамическом SQL, очевидно).
Ваше тестовое выражение должно оцениваться в WHERE
блоке, а не SELECT
. Отправленный вами SQL недействителен и не будет выполняться, поэтому мне любопытно, как вы получаете результаты, которые видите.
Попробуйте это:
SELECT
id AS cid,
designation,
division_name,
pin_no,
username
FROM
application_user
WHERE
( $P{internal} = 'internal' AND username LIKE '%_@__%.__%' )
OR
( $P{internal} <> 'internal' AND username NOT LIKE '%_@__%.__%' )
Обратите внимание, что это не обязательно приведет к наилучшему плану выполнения во время выполнения из-за разной эффективной «формы» запроса в зависимости от значения параметра. В идеале у вас должно быть два разных запроса, выбранных вашим кодом приложения, которые имеют разные username
предикаты.
Комментарии:
1. На самом деле, поскольку в
like
нем есть все эти подстановочные знаки, было бы сложно предотвратить выполнение этим запросом сканирования всей таблицы. Таким образом, производительность не является большой проблемой.