Этот баннер — требование Роскомнадзора для исполнения 152 ФЗ.
«На сайте осуществляется обработка файлов cookie, необходимых для работы сайта, а также для анализа использования сайта и улучшения предоставляемых сервисов с использованием метрической программы Яндекс.Метрика. Продолжая использовать сайт, вы даёте согласие с использованием данных технологий».
Политика конфиденциальности
|
|
|
Хорошее объяснение почему так делать нельзя
|
|||
|---|---|---|---|
|
#18+
У меня есть запрос, который левым джойном связывает пару таблиц таким образом: coalesce(char(L1.A_ID),'9999999') = coalesce(char(L2.A_ID),'9999999') Никто случайно не встречал в и-нете популярное изложение почему так делать нельзя. И желательно на английском))))))) С моей точки зрения сервер БД не знает как будут связаны таблицы до тех пор пока не будут посчитаны функции. А функции будут посчитаны только в момент выполнения. И в результате всегда будет сканирование таблиц и всегда будет медленно. Правильное объяснение? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.11.2008, 12:54 |
|
||
|
Хорошее объяснение почему так делать нельзя
|
|||
|---|---|---|---|
|
#18+
По-моему да.... Во всяком случае, как только применяю функцию по столбцу, то индексы уже не используются по этому столбцу.... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.11.2008, 14:00 |
|
||
|
Хорошее объяснение почему так делать нельзя
|
|||
|---|---|---|---|
|
#18+
Почитайте про 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. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.11.2008, 14:09 |
|
||
|
Хорошее объяснение почему так делать нельзя
|
|||
|---|---|---|---|
|
#18+
O! Марк! в самую точку, то, что надо! Пошлю нашим забугорным коллегам. Большое спасибо)))... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.11.2008, 17:46 |
|
||
|
Хорошее объяснение почему так делать нельзя
|
|||
|---|---|---|---|
|
#18+
gardenmanO! Марк! в самую точку, то, что надо! Пошлю нашим забугорным коллегам. Большое спасибо)))... а смысл отправлять? нужно предложить альтернативу )))) а альтернативой будет тупой подход использования вместо NULL пробела или иных "магических" символов, что лично мне совсем не нравится. Поэтому это палка о 2-х концах. имхо Наверное есть и др. решения, поделитесь..... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 07.11.2008, 12:06 |
|
||
|
Хорошее объяснение почему так делать нельзя
|
|||
|---|---|---|---|
|
#18+
Такие выражения приходится разбивать на пару выражений и использовать промежуточную временную таблицу. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 07.11.2008, 14:38 |
|
||
|
Хорошее объяснение почему так делать нельзя
|
|||
|---|---|---|---|
|
#18+
а разве в db2 нельзя через некий index extension сделать индекс по функции ? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 07.11.2008, 19:36 |
|
||
|
Хорошее объяснение почему так делать нельзя
|
|||
|---|---|---|---|
|
#18+
Yo.!, Не уверен что это хороший выход из положения. И в некоторых случаях он просто неприемлем. Для того, чтобы использовать указанную вами фичу необходимо писать функции на С, и соответственно подложить соответствующие DLL на сервер. А когда нужно это делать динамически, ясный пень, это неприемлемо. При всем при этом индексные расширения весьма специфичны. И работа по ним ведется особым образом. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 08.11.2008, 23:58 |
|
||
|
Хорошее объяснение почему так делать нельзя
|
|||
|---|---|---|---|
|
#18+
Вообще-то обещают сделать индексацию по функциям. Только вот боюсь что выигрыша в производительности от этого не будет, а SQL станет запутанней. Наверное поэтому IBM и не торопится с реализацией. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 09.11.2008, 00:00 |
|
||
|
Хорошее объяснение почему так делать нельзя
|
|||
|---|---|---|---|
|
#18+
gardenman Только вот боюсь что выигрыша в производительности от этого не будет, а SQL станет запутанней читать пару блоков индекса вместо террабайтов фулсканом в оракле дает достаточно заметный выйгрыш, да и команда create index не изменилась ... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 09.11.2008, 16:20 |
|
||
|
Хорошее объяснение почему так делать нельзя
|
|||
|---|---|---|---|
|
#18+
Index extension - не для таких случаев. Здесь можно применить стандартный подход - создать в обеих таблицах generated always поле по этому выражению и индекс на это поле. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 10.11.2008, 09:57 |
|
||
|
Хорошее объяснение почему так делать нельзя
|
|||
|---|---|---|---|
|
#18+
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. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 18.11.2008, 09:17 |
|
||
|
Хорошее объяснение почему так делать нельзя
|
|||
|---|---|---|---|
|
#18+
Какая разница какую функцию применять? все равно будет медленно. Как правильно сказал Марк - тут ток автогенерируемое поле поможет. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 18.11.2008, 11:35 |
|
||
|
Хорошее объяснение почему так делать нельзя
|
|||
|---|---|---|---|
|
#18+
Разница большая. В первом примере приходится делать приведение типа - char(). Да, в этом случае лучше сразу держать данные в виде строки. В случае конструкции CASE или функции DECODE нет приведения типа. В итоге, сводится к использованию дополнительного оператора OR: Код: plaintext В той статье, что привел Марк, сказано - "если возможно, не используйте оператор OR...". В данном случае мы сталкиваемся с тем, что сравнение двух пустых полей даст отрицательный результат. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 18.11.2008, 12:55 |
|
||
|
Хорошее объяснение почему так делать нельзя
|
|||
|---|---|---|---|
|
#18+
Вопрос - будет ли в этом случае использоваться индекс? И можно ли сделать так, чтобы использовался индекс для соединения таблиц? Если нет - то такая конструкция не нужна однозначно. Производительность на больших таблицах будет очень плохой. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 18.11.2008, 13:17 |
|
||
|
Хорошее объяснение почему так делать нельзя
|
|||
|---|---|---|---|
|
#18+
gardenmanКакая разница какую функцию применять? все равно будет медленно. Как правильно сказал Марк - тут ток автогенерируемое поле поможет.Ещё может помочь переход на iSeries, там есть прикольное выражение http://publib.boulder.ibm.com/infocenter/iseries/v5r3/topic/sqlp/rbafynulls.htm]IS [NOT] DISTINCT FROM . :) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 18.11.2008, 14:15 |
|
||
|
|

start [/forum/topic.php?fid=43&msg=35640207&tid=1603582]: |
0ms |
get settings: |
8ms |
get forum list: |
9ms |
check forum access: |
2ms |
check topic access: |
2ms |
track hit: |
201ms |
get topic data: |
7ms |
get forum data: |
2ms |
get page messages: |
37ms |
get tp. blocked users: |
1ms |
| others: | 232ms |
| total: | 501ms |

| 0 / 0 |
