|
может кто-нибудь знает
|
|||
---|---|---|---|
#18+
Можно ли как-то заставить проверяться могут ли существовать строки удовлетворяющие данному условию. Мне нужно различать результат в следующих вариантах. Пример таблицы SAMPLE ID 2 3 5 7 Мне нужно чтобы результат SELECT 1 FROM DUAL WHERE EXISTS(SELECT * FROM SAMPLE WHERE ID>3 AND ID<5) был бы одним а SELECT 1 FROM DUAL WHERE EXISTS(SELECT * FROM SAMPLE WHERE ID>5 AND ID<3) другим Точнее мне нужно как раз отлавливать только вторые ситуации. Чем бы это получить. ... |
|||
:
Нравится:
Не нравится:
|
|||
10.12.2002, 10:53 |
|
может кто-нибудь знает
|
|||
---|---|---|---|
#18+
SELECT 1 FROM DUAL WHERE EXISTS(SELECT * FROM SAMPLE WHERE ID>5 AND ID<3) А как ID может одновременно быть больше 5 и меньше 3? Это новое слово в математике. ... |
|||
:
Нравится:
Не нравится:
|
|||
10.12.2002, 11:15 |
|
может кто-нибудь знает
|
|||
---|---|---|---|
#18+
В математике может и новое, но на практике это вполне нормальное условие в WHERE condition Просто такое множество не существует не только в базе но и в природе. Вот мне нужен признак которые говорил бы что при этих условиях не может существовать ни одной строчки. Ни сейчас ни потом. ... |
|||
:
Нравится:
Не нравится:
|
|||
10.12.2002, 14:05 |
|
может кто-нибудь знает
|
|||
---|---|---|---|
#18+
так может всеже ID > 5 OR ID < 3 ?? ... |
|||
:
Нравится:
Не нравится:
|
|||
10.12.2002, 14:45 |
|
может кто-нибудь знает
|
|||
---|---|---|---|
#18+
Для этого условия "WHERE ID>5 AND ID<3" запроса, я вижу только такой смысл: все строки у которых ID<=5 - не удовлетворяет условию. В этом случае второе условие "ID<3" уже не будет проверяться, что в каком смысле оптимизирует запрос. Однако если же ID>5, то проверятся второе условие, а так как второе условие противоречит первому, то это автоматически приводит к тому что все строки, у которых ID>5, также не удовлетворяет условию. Отсюда вывод:запрос Код: plaintext 1.
всегда будет возвращать 0 строк, так как EXISTS всегда будет возвращать FALSE. Поэтому слова "это вполне нормальное условие в WHERE condition Просто такое множество не существует не только в базе но и в природе" могут воспиниматься только как параноидальный бред. Единственный смысл я вижу только в том случае, когда значения 3 и 5 - это не конкрентные значения, а значения переменных привязки или подстановки, то есть критерии поиска, которые указывает пользователь, который иногда может задавать их некорректно. Признак которые говорил бы что при этих условиях не может существовать ни одной строчки - это просто - если вторая переменная меньше первой. Или определять разницу между вторым и первым числом и определять знак. Если "-" то и есть признак. ... |
|||
:
Нравится:
Не нравится:
|
|||
10.12.2002, 15:14 |
|
может кто-нибудь знает
|
|||
---|---|---|---|
#18+
Я кажется понял. Необходимо различать, почему запрос не вернул ни одной строки. То-ли нет строк, удовлетворяющих данному условию, то-ли условие составлено некорректно. Только для этого, боюсь, надо делать семантический анализ самого запроса (условия where). Oracle здесь не помощник. ... |
|||
:
Нравится:
Не нравится:
|
|||
10.12.2002, 15:54 |
|
может кто-нибудь знает
|
|||
---|---|---|---|
#18+
SQL>SELECT 1 FROM DUAL WHERE EXISTS(SELECT * FROM SAMPLE WHERE ID>3 AND ID<5) ; 1 ---------- 1 SQL>SELECT 0 FROM DUAL WHERE EXISTS(SELECT * FROM SAMPLE WHERE ID>5 or ID<3) ; 0 ---------- 0 ... |
|||
:
Нравится:
Не нравится:
|
|||
10.12.2002, 17:57 |
|
может кто-нибудь знает
|
|||
---|---|---|---|
#18+
Совершенно прав Noname от 15:54 Этот условие генериться програмно , точнее говоря двумя программами, которые общаются через базу. Хотелось бы получать сообщение о "некорректности условий". Однако вижу ничего не получается. Анализатор писать не хочется, тормозить всё будет, но ... ... |
|||
:
Нравится:
Не нравится:
|
|||
10.12.2002, 19:16 |
|
может кто-нибудь знает
|
|||
---|---|---|---|
#18+
Если охота проверять "правильность" условий не в общем случае, а для конкретной таблицы с конкретными данными наподобе: Код: plaintext 1. 2. 3. 4.
можно, к примеру, сперва сделать запрос из вспомогательной таблицы, в которой наверняка присутствуют _все_ значения из диапазона между наименьшим и наибольшим значением параметров, технология таких запросов описана вот здесь: http://otn.oracle.com/oramag/oracle/02-sep/o52sql.html и если этот вспомогательный запрос не вернул ни одной записи, значит, что-то не так... Но в случае необходимости получения результатов при помощи больше чем одним запросом меня всегда смущает возможность рассинхронизации данных: между двумя запросами содержимое таблицы может измениться. ... |
|||
:
Нравится:
Не нравится:
|
|||
10.12.2002, 20:04 |
|
может кто-нибудь знает
|
|||
---|---|---|---|
#18+
К сожалению это мне никак не помогает. Запросы могут быть абсолютно бредовыми с любыми заворотами типа LIKE или EXISTS ... |
|||
:
Нравится:
Не нравится:
|
|||
10.12.2002, 20:16 |
|
может кто-нибудь знает
|
|||
---|---|---|---|
#18+
"Бредовые" запросы из одной таблицы- это в схему укладывается. Другое принципиально: они выбирают данные из разных таблиц с разной структурой? Если да, то пытаться поймать разницу ответов "может возвратить" и "должен возвратить" имхо не стоит. ... |
|||
:
Нравится:
Не нравится:
|
|||
10.12.2002, 20:24 |
|
может кто-нибудь знает
|
|||
---|---|---|---|
#18+
Это запрос по одной таблице, но в Where clause может очутиться подзапрос типа Код: plaintext
... |
|||
:
Нравится:
Не нравится:
|
|||
10.12.2002, 20:30 |
|
может кто-нибудь знает
|
|||
---|---|---|---|
#18+
Тогда обойтись без ручной разборки запроса можно лишь при возможности классифицировать все возможные условия, т.е. составить их список (без конкретных значений параметров привязки) и проверять каждый по отдельности. В общем же случае, повторюсь, задача может быть не для pl/sql. ... |
|||
:
Нравится:
Не нравится:
|
|||
10.12.2002, 20:39 |
|
|
start [/forum/topic.php?fid=52&fpage=2827&tid=1992497]: |
0ms |
get settings: |
9ms |
get forum list: |
13ms |
check forum access: |
4ms |
check topic access: |
4ms |
track hit: |
34ms |
get topic data: |
12ms |
get forum data: |
3ms |
get page messages: |
47ms |
get tp. blocked users: |
2ms |
others: | 296ms |
total: | 424ms |
0 / 0 |