Гость
Целевая тема:
Создать новую тему:
Автор:
Форумы / IBM DB2, WebSphere, IMS, U2 [игнор отключен] [закрыт для гостей] / Хорошее объяснение почему так делать нельзя / 16 сообщений из 16, страница 1 из 1
06.11.2008, 12:54
    #35637290
gardenman
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Хорошее объяснение почему так делать нельзя
У меня есть запрос, который левым джойном связывает пару таблиц таким образом:

coalesce(char(L1.A_ID),'9999999') = coalesce(char(L2.A_ID),'9999999')

Никто случайно не встречал в и-нете популярное изложение почему так делать нельзя. И желательно на английском)))))))

С моей точки зрения сервер БД не знает как будут связаны таблицы до тех пор пока не будут посчитаны функции. А функции будут посчитаны только в момент выполнения. И в результате всегда будет сканирование таблиц и всегда будет медленно.

Правильное объяснение?
...
Рейтинг: 0 / 0
06.11.2008, 14:00
    #35637569
TORT
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Хорошее объяснение почему так делать нельзя
По-моему да.... Во всяком случае, как только применяю функцию по столбцу, то индексы уже не используются по этому столбцу....
...
Рейтинг: 0 / 0
06.11.2008, 14:09
    #35637603
Mark Barinstein
Гость
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Хорошее объяснение почему так делать нельзя
Почитайте про efficient select statements .
Там в конце есть:
* If possible, avoid using expressions or OR clauses with join predicates because the database manager cannot use some join techniques. As a result, the most efficient join method may not be chosen.
...
Рейтинг: 0 / 0
06.11.2008, 17:46
    #35638392
gardenman
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Хорошее объяснение почему так делать нельзя
O! Марк! в самую точку, то, что надо!
Пошлю нашим забугорным коллегам.
Большое спасибо)))...
...
Рейтинг: 0 / 0
07.11.2008, 12:06
    #35639646
use-se
Гость
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Хорошее объяснение почему так делать нельзя
gardenmanO! Марк! в самую точку, то, что надо!
Пошлю нашим забугорным коллегам.
Большое спасибо)))...
а смысл отправлять?
нужно предложить альтернативу ))))
а альтернативой будет тупой подход
использования вместо NULL пробела или иных
"магических" символов, что лично мне совсем не нравится.
Поэтому это палка о 2-х концах. имхо
Наверное есть и др. решения, поделитесь.....
...
Рейтинг: 0 / 0
07.11.2008, 14:38
    #35640207
gardenman
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Хорошее объяснение почему так делать нельзя
Такие выражения приходится разбивать на пару выражений и использовать промежуточную временную таблицу.
...
Рейтинг: 0 / 0
07.11.2008, 19:36
    #35641033
Yo.!
Гость
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Хорошее объяснение почему так делать нельзя
а разве в db2 нельзя через некий index extension сделать индекс по функции ?
...
Рейтинг: 0 / 0
08.11.2008, 23:58
    #35642093
gardenman
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Хорошее объяснение почему так делать нельзя
Yo.!,

Не уверен что это хороший выход из положения. И в некоторых случаях он просто неприемлем.
Для того, чтобы использовать указанную вами фичу необходимо писать функции на С, и соответственно подложить соответствующие DLL на сервер. А когда нужно это делать динамически, ясный пень, это неприемлемо. При всем при этом индексные расширения весьма специфичны. И работа по ним ведется особым образом.
...
Рейтинг: 0 / 0
09.11.2008, 00:00
    #35642094
gardenman
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Хорошее объяснение почему так делать нельзя
Вообще-то обещают сделать индексацию по функциям. Только вот боюсь что выигрыша в производительности от этого не будет, а SQL станет запутанней. Наверное поэтому IBM и не торопится с реализацией.
...
Рейтинг: 0 / 0
09.11.2008, 16:20
    #35642427
Yo.!
Гость
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Хорошее объяснение почему так делать нельзя
gardenman Только вот боюсь что выигрыша в производительности от этого не будет, а SQL станет запутанней
читать пару блоков индекса вместо террабайтов фулсканом в оракле дает достаточно заметный выйгрыш, да и команда create index не изменилась ...
...
Рейтинг: 0 / 0
10.11.2008, 09:57
    #35643124
Mark Barinstein
Гость
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Хорошее объяснение почему так делать нельзя
Index extension - не для таких случаев.
Здесь можно применить стандартный подход - создать в обеих таблицах generated always поле по этому выражению и индекс на это поле.
...
Рейтинг: 0 / 0
18.11.2008, 09:17
    #35659463
gals
Гость
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Хорошее объяснение почему так делать нельзя
gardenmanУ меня есть запрос, который левым джойном связывает пару таблиц таким образом:

coalesce(char(L1.A_ID),'9999999') = coalesce(char(L2.A_ID),'9999999')

Если у вас DB2 9.5, можно применить функцию DECODE.
DECODE(L1.A_ID, L2.A_ID, 1, 0) = 1

Вот, что пишется в документации:
Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
Similarly, the DECODE expression:
   DECODE (c1, var1, ’a’, var2, ’b’)
where the values of c1, var1, and var2 could be null values, achieves the same
result as the following CASE expression:
   CASE
     WHEN c1 = var1 OR (c1 IS NULL AND var1 IS NULL) THEN ’a’
     WHEN c1 = var2 OR (c1 IS NULL AND var2 IS NULL) THEN ’b’
     ELSE NULL
   END
...
Рейтинг: 0 / 0
18.11.2008, 11:35
    #35659861
gardenman
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Хорошее объяснение почему так делать нельзя
Какая разница какую функцию применять? все равно будет медленно.
Как правильно сказал Марк - тут ток автогенерируемое поле поможет.
...
Рейтинг: 0 / 0
18.11.2008, 12:55
    #35660173
gals
Гость
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Хорошее объяснение почему так делать нельзя
Разница большая. В первом примере приходится делать приведение типа - char(). Да, в этом случае лучше сразу держать данные в виде строки.
В случае конструкции CASE или функции DECODE нет приведения типа. В итоге, сводится к использованию дополнительного оператора OR:
Код: plaintext
L1.A_ID = L2.A_ID OR (L1.A_ID IS NULL AND L2.A_ID IS NULL)

В той статье, что привел Марк, сказано - "если возможно, не используйте оператор OR...".
В данном случае мы сталкиваемся с тем, что сравнение двух пустых полей даст отрицательный результат.
...
Рейтинг: 0 / 0
18.11.2008, 13:17
    #35660275
gardenman
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Хорошее объяснение почему так делать нельзя
Вопрос - будет ли в этом случае использоваться индекс? И можно ли сделать так, чтобы использовался индекс для соединения таблиц? Если нет - то такая конструкция не нужна однозначно. Производительность на больших таблицах будет очень плохой.
...
Рейтинг: 0 / 0
18.11.2008, 14:15
    #35660546
Mark Barinstein
Гость
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Хорошее объяснение почему так делать нельзя
gardenmanКакая разница какую функцию применять? все равно будет медленно.
Как правильно сказал Марк - тут ток автогенерируемое поле поможет.Ещё может помочь переход на iSeries, там есть прикольное выражение http://publib.boulder.ibm.com/infocenter/iseries/v5r3/topic/sqlp/rbafynulls.htm]IS [NOT] DISTINCT FROM . :)
...
Рейтинг: 0 / 0
Форумы / IBM DB2, WebSphere, IMS, U2 [игнор отключен] [закрыт для гостей] / Хорошее объяснение почему так делать нельзя / 16 сообщений из 16, страница 1 из 1
Найденые пользователи ...
Разблокировать пользователей ...
Читали форум (0):
Пользователи онлайн (0):
x
x
Закрыть


Просмотр
0 / 0
Close
Debug Console [Select Text]