Мастера DELPHI (документация, исходники, скачать)

Основная («Начинающим»)/ Базы / WinAPI / Компоненты / Сети / Media / Игры / Corba и COM / KOL / FreePascal / .Net / Прочее / RSDN.ORG

« предыдущая ветвь | форум | следующая ветвь »

Не работает ORDER BY [D7, IB6.x]

Страницы: 1 2 >
oleg_p © (2005-09-12 08:31:00)
При выполнении запроса
SELECT PROPERTY.ID_ABS, PROP_DSC.NAME, PROP_DSC.CODE, PROP_DSC.VALUE_TYPE, PROP_DSC.POINTER_TYPE, PROP_DSC.LIST, PROPERTY.PROP_DATA, PROP_DATA_F.DATA AS DATA_F, PROP_DATA_I.DATA AS DATA_I, PROP_DATA_S.DATA AS DATA_S FROM PROP_DSC, PROPERTY LEFT OUTER JOIN PROP_DATA_F ON PROP_DATA_F.ID=PROPERTY.PROP_DATA LEFT OUTER JOIN PROP_DATA_I ON PROP_DATA_I.ID=PROPERTY.PROP_DATA LEFT OUTER JOIN PROP_DATA_S ON PROP_DATA_S.ID=PROPERTY.PROP_DATA WHERE PROP_DSC.ID=PROPERTY.PROP_DSC AND PROPERTY.ID_OBJ=:ID_OBJ AND PROP_DSC.IS_GROUP='F' AND PROP_DSC.PARENT=:PARENT ORDER BY PROP_DSC.ORD

таблица оказывается отсортированной не по PROP_DSC.ORD,
а по первичному индексу таблицы PROP_DSC. Если убрать все OUTER JOIN - сортировка идет нормально.

Fay (2005-09-14 06:45:00) [1]
2 Deniz © (14.09.05 6:25) [21]
Не понимаю, как можно испортить жизнь оптимизатору, который годами путает left join и inner join.

Deniz (2005-09-14 06:25:00) [2]
>Desdechado © (13.09.05 11:43) [20]
Спасибо, конечно, за консультацию, но все это я давно знаю.
Про OUTER JOIN я ничего не говорил.
Ты меня как-то не так понял. Я имел ввиду что, в одном select'е использовать явные и неявные объединения таблиц не есть гуд и привел пример как это должно выглядеть с inner join.

>oleg_p (13.09.05 08:01) [19]
>Нехорошо, в смысле код некрасивый? Или есть более объективные причины?

Во-первых: есть вероятность, что в последствии ты забудешь прописать в where условие объединения, и результат окажется неверный.
Во-вторых: такой подход усложняет жизнь оптимизатору.
И в-последних: если память не изменяет, то в FireBird 2, такой код будет выдавать предупреждение или ошибку.

Desdechado (2005-09-13 11:43:00) [3]
Deniz © (13.09.05 07:33) [18]
А вот использование OUTER JOIN - вполне нормальное явление. Для того оно и придумано в языке, чтоб даже отсутствующие в другой таблице данные использовать, что INNER JOIN не позволяет.

oleg_p (2005-09-13 08:01:00) [4]
Во-первых, спасибо всем за помощь.

> Desdechado © (12.09.05 13:12) [16]
Поле ORD сделано специально для сортировки,чтобы иметь возможность поменять местами две соседние записи просто обменявшись значениями ORD (Fay [17] верно сказал). При этом знать, что в нём содержится пользователю не надо вообще.

> Deniz © (13.09.05 07:33) [18]
> переведи объединение PROP_DSC и PROPERTY в inner join, а то как-то нехорошо получается.

Нехорошо, в смысле код некрасивый? Или есть более объективные причины?

Deniz (2005-09-13 07:33:00) [5]
+ дополню
Дурной тон это:
... FROM PROP_DSC, PROPERTY LEFT OUTER JOIN ...
переведи объединение PROP_DSC и PROPERTY в inner join, а то как-то нехорошо получается.
... FROM PROP_DSC INNER JOIN PROPERTY ON PROP_DSC.ID=PROPERTY.PROP_DSC LEFT OUTER JOIN PROP_DATA_F ON PROP_DATA_F.ID=PROPERTY.PROP_DATA LEFT OUTER JOIN PROP_DATA_I ON PROP_DATA_I.ID=PROPERTY.PROP_DATA LEFT OUTER JOIN PROP_DATA_S ON PROP_DATA_S.ID=PROPERTY.PROP_DATA ...

Fay (2005-09-12 16:07:00) [6]
2 Desdechado © (12.09.05 13:12) [16]
Представь себе, что мне интересно в каком порядке происходили некие события, но совершенно наплевать когда именно.

Desdechado (2005-09-12 13:12:00) [7]
вольному воля...
сортировать яблоки по дереву, с которого они собраны, не указывая этого самого дерева - странно, почти бессмысленно, имхо

Fay (2005-09-12 12:41:00) [8]
2 Desdechado © (12.09.05 11:45) [14]
>> сортировка по полю, отсутствующему в SELECT, - очень дурной тон

Бред

Desdechado (2005-09-12 11:45:00) [9]
вообще-то сортировка по полю, отсутствующему в SELECT, - очень дурной тон
большинство серверов обрабатывают это по-своему, если вообще обрабатывают

oleg_p (2005-09-12 11:20:00) [10]
Удалил индекс по полю PROP_DSC.ORD - ВСЕ ЗАРАБОТАЛО !!
Создаю индекс заново - опять не сортирует.
Придется пожить без индекса :-(

oleg_p (2005-09-12 11:03:00) [11]
> Prohodil Mimo © (12.09.05 10:54) [11]
Так их там вроде и нет ???

Prohodil Mimo (2005-09-12 10:54:00) [12]
A jesli v kachestve imjon polej ne ispol'zovat' zarezervirovannije slova?

oleg_p (2005-09-12 10:46:00) [13]
... PROP_DSC_IDX1- это индекс на поле PROP_DSC.ORD

Stakan (2005-09-12 10:46:00) [14]
Когда-то сталкивался с такой ошибкой. Помогло создание индекса по полю в order by

oleg_p (2005-09-12 10:38:00) [15]
Поставил IB 6.5 на другой машине, переписал туда базу. Попробовал тот же запрос сначала в IBExpert удаленно через сеть, потом в IBConsole локально. Абсолютно тот же результат.

Сортировка идет либо по полю PROPERTY.ID_ABS либо по полю PROP_DSC.ID - они оба по сортировке дают один результат,поэтому точно не скажу. Оба поля в PRRIMARY KEY.

Может план запроса натолкнет на мысль:
PLAN MERGE ( SORT (PROP_DSC ORDER PROP_DSC_IDX1), SORT (JOIN (JOIN (JOIN (PROPERTY NATURAL,PROP_DATA_F INDEX (RDB$PRIMARY38)),PROP_DATA_I INDEX (RDB$PRIMARY43)),PROP_DATA_S INDEX (RDB$PRIMARY45))))

Sergey13 (2005-09-12 10:12:00) [16]
2 [5] oleg_p (12.09.05 09:57)
>Так на ней и работаю - Firebird 1.0.2.
Тогда попробуй поставить помоложе.

ANB (2005-09-12 10:02:00) [17]

> oleg_p (12.09.05 09:57) [5]
- значит либо версия кривая, либо стоит криво. Стандарт SQL обязывает твою конструкцию работать.

oleg_p (2005-09-12 09:57:00) [18]
>А если попробовать Жар птицу?

Так на ней и работаю - Firebird 1.0.2. Надо конечно попробовать чё-нидь ещё ... попробую ib 6.0 поставить.

Sergey13 (2005-09-12 09:44:00) [19]
А если попробовать Жар птицу?

oleg_p (2005-09-12 09:39:00) [20]
> Не могет такого быть. Значит order by отвалился при формировании запроса. Чем выполняешь ?

В IBDataSet.SelectSQL. Также пробовал в IBExpert - результат тот же.

> Попробуй вставить PROP_DSC.ORD в список полей Select
Уже пробовал - не помогает.

Страницы: 1 2 >

Наверх

	« предыдущая ветвь \| форум \| следующая ветвь »