|
FB3, join vs LIKE vs case-sensitivity
|
|||
---|---|---|---|
#18+
Очень неконкретный отчёт. https://stackoverflow.com/questions/56858452/why-did-my-where-clause-affect-my-left-join Якобы, сравниваются два запроса на одной БД. Код: sql 1. 2. 3. 4. 5. 6. 7. 8.
Якобы, в обоих случаях находится одна и та же строка мастер-таблицы (с кодом 'ABC'). Но при этом из вторoй таблицы строка подтягивается только во втором случае, а в первом - NULL. Кто-нибудь сталкивался с чем-то таким ? ... |
|||
:
Нравится:
Не нравится:
|
|||
03.07.2019, 12:09 |
|
FB3, join vs LIKE vs case-sensitivity
|
|||
---|---|---|---|
#18+
03.07.2019 12:09, Arioch пишет: > Кто-нибудь сталкивался с чем-то таким ? только читал про такие симптомы. это грибы. Posted via ActualForum NNTP Server 1.5 ... |
|||
:
Нравится:
Не нравится:
|
|||
03.07.2019, 12:13 |
|
FB3, join vs LIKE vs case-sensitivity
|
|||
---|---|---|---|
#18+
Arioch, Ты бы хоть поглядел, что именно оно якобы возвращает. Если в первом случае LEFT JOIN не отобрал, то как у него вернулось значение в PRODUCTS.code? Короче, мы такое не курим. ... |
|||
:
Нравится:
Не нравится:
|
|||
03.07.2019, 12:19 |
|
FB3, join vs LIKE vs case-sensitivity
|
|||
---|---|---|---|
#18+
я глядел, и даже вопрос про это в комментах оставил а вот ты, стало быть, не глядел пример он явно "из головы" делал, а не из реальной БД с реальными чужими данными ... |
|||
:
Нравится:
Не нравится:
|
|||
03.07.2019, 13:22 |
|
FB3, join vs LIKE vs case-sensitivity
|
|||
---|---|---|---|
#18+
Там разные коллейты в сравниваемых полях. На это никто не обратил внимание. ... |
|||
:
Нравится:
Не нравится:
|
|||
03.07.2019, 13:27 |
|
FB3, join vs LIKE vs case-sensitivity
|
|||
---|---|---|---|
#18+
hvlad, это предполагается, но точно не названо в любом случае, это ведь не должно менять результат ... |
|||
:
Нравится:
Не нравится:
|
|||
03.07.2019, 13:40 |
|
FB3, join vs LIKE vs case-sensitivity
|
|||
---|---|---|---|
#18+
Т.к. пациент явно путается в показаниях и пишет не то что видит - это важно. ... |
|||
:
Нравится:
Не нравится:
|
|||
03.07.2019, 13:55 |
|
FB3, join vs LIKE vs case-sensitivity
|
|||
---|---|---|---|
#18+
ОК, воспроизвожу на коленке на FB 2.1 (что под руками было) Код: sql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. 23. 24. 25. 26. 27. 28. 29. 30. 31. 32. 33. 34. 35. 36. 37. 38. 39. 40. 41. 42. 43. 44. 45. 46.
Как-то это ненормально.... ... |
|||
:
Нравится:
Не нравится:
|
|||
03.07.2019, 14:20 |
|
FB3, join vs LIKE vs case-sensitivity
|
|||
---|---|---|---|
#18+
В общем видe: Kакие charset/collate используются для вычисления "T_CS.id = T_CI.id" ? Те же самые по идее надо использовать, если решили - ** на основе именно этого условия ** - спускать LIKE на уровень ниже ... |
|||
:
Нравится:
Не нравится:
|
|||
03.07.2019, 14:24 |
|
FB3, join vs LIKE vs case-sensitivity
|
|||
---|---|---|---|
#18+
Arioch, прекратите использовать дурацкие * для начала. Не хрена ж не понятно какие поля и в каком порядке выводятся. и результат в таком виде не фига не понятный Arioch-- OK: data ~ data что нельзя написать какие именно значения выводятся? автор-- ????? data ~ NULL ????? если оба поля из T_CS равны NULL, то как раз всё нормально, а вот если как у автора на stackoverflow, то нет ... |
|||
:
Нравится:
Не нравится:
|
|||
03.07.2019, 14:29 |
|
FB3, join vs LIKE vs case-sensitivity
|
|||
---|---|---|---|
#18+
Вам скрипт в зубы дали, готовый, запустите и форматируйте как вам удобно. Какие данные выводятся вполне понятно - в каждой таблицы одна единственная строчка. Она либо выводится, либо нет. ... |
|||
:
Нравится:
Не нравится:
|
|||
03.07.2019, 14:31 |
|
FB3, join vs LIKE vs case-sensitivity
|
|||
---|---|---|---|
#18+
> если оба поля из T_CS равны NULL, то как раз всё нормально это НЕ нормально, потому что необъяснимо с точки зрения SQL на T_CS там условие одно единственное и на этих данных оно выполняется ВСЕГДА, независимо от коллейтов что оптимизатор крышей поехал, такая реализация - да, *так* объяснимо ... |
|||
:
Нравится:
Не нравится:
|
|||
03.07.2019, 14:33 |
|
FB3, join vs LIKE vs case-sensitivity
|
|||
---|---|---|---|
#18+
Arioch, ну вообще-то там конечно есть недостаток в том, что предикат фильтрации может проталкиваться далее через условия сравнения. Но в большинстве случаев это несёт пользу. А вот как можно додумался условие связи делать по текстовым полям с разными COLLATE вот это вопрос к проектировщику. ... |
|||
:
Нравится:
Не нравится:
|
|||
03.07.2019, 14:44 |
|
FB3, join vs LIKE vs case-sensitivity
|
|||
---|---|---|---|
#18+
03.07.2019 14:20, Arioch пишет: > что primary key надо вставлять МЕЖДУ charset и collate - это интересно кто так догадался? создатели стандарта SQL. (на заре компьютерной эпохи) вообще-то, так не надо делать. по хорошему, для PK нужно декларировать CONSTRAINT. Код: sql 1. 2. 3. 4.
Posted via ActualForum NNTP Server 1.5 ... |
|||
:
Нравится:
Не нравится:
|
|||
03.07.2019, 14:45 |
|
FB3, join vs LIKE vs case-sensitivity
|
|||
---|---|---|---|
#18+
Выше план не читать, он от другого запросу. От проблемного ожидаемое Код: plaintext 1. 2. 3. 4.
... |
|||
:
Нравится:
Не нравится:
|
|||
03.07.2019, 14:46 |
|
FB3, join vs LIKE vs case-sensitivity
|
|||
---|---|---|---|
#18+
Ну и ещё ожидаемое, если всё-таки подключить индекс по мастер-таблице, а не по подчинённой, то снова работает. Код: sql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13.
... |
|||
:
Нравится:
Не нравится:
|
|||
03.07.2019, 14:50 |
|
FB3, join vs LIKE vs case-sensitivity
|
|||
---|---|---|---|
#18+
Ariochа вот ты, стало быть, не гляделЯ все комменты не читаю. Много воды, мусора и вот этого. AriochВыше план не читать ... |
|||
:
Нравится:
Не нравится:
|
|||
03.07.2019, 14:52 |
|
FB3, join vs LIKE vs case-sensitivity
|
|||
---|---|---|---|
#18+
насколько я понимаю, из (T_CS.id = T_CI.id) и (T_CI.id like '%bc%') оптимизатор вывел еще и (T_CS.id like '%bc%'), которое есс-но вычисляется как false внутри условия джойна, возвращая NULL для правой части. ... |
|||
:
Нравится:
Не нравится:
|
|||
03.07.2019, 14:53 |
|
FB3, join vs LIKE vs case-sensitivity
|
|||
---|---|---|---|
#18+
Симонов Денис, Это несёт пользу, но если делать правильно.... А почему нельзя? а связки по полям разного числового типа можно делать или тоже запрещено? bigint и smallint например можно сравнивать в JOIN'e ? ... |
|||
:
Нравится:
Не нравится:
|
|||
03.07.2019, 14:54 |
|
FB3, join vs LIKE vs case-sensitivity
|
|||
---|---|---|---|
#18+
dimitr, ну это единственное объяснение.... т.е. оптимизатор догадался пропихнуть вниз LIKE но не догадался пропихнуть связанный с этим условиенм charset&collate плюс наложился натуральный скан мастер-таблицы ввиду поиска не с начала строки ... |
|||
:
Нравится:
Не нравится:
|
|||
03.07.2019, 14:56 |
|
FB3, join vs LIKE vs case-sensitivity
|
|||
---|---|---|---|
#18+
просто для добавления новых предикатов по принципу эквивалентности, недостаточно брать за основу любое равенство. Надо еще убедиться, что коллейты по обе стороны совпадают. Вот тогда можно оптимизировать как сейчас. А иначе нефиг. ... |
|||
:
Нравится:
Не нравится:
|
|||
03.07.2019, 15:01 |
|
FB3, join vs LIKE vs case-sensitivity
|
|||
---|---|---|---|
#18+
dimitr, на мой взгляд нужно проталкивать вместе с коллейтом когда ты сравниваешь signed int 32 и unsigned int 32 ты оба расширяешь до int 64, например с чарсетами и коллейтами должно происходить аналогичное приведение к некоему общему надмножеству и оно должно использоваться не только для самого сравнения, но и для всех вторичных, порождённых этим сравнением действий Но это "идеалистическoе" рассуждение, 21919886 ... |
|||
:
Нравится:
Не нравится:
|
|||
03.07.2019, 15:04 |
|
FB3, join vs LIKE vs case-sensitivity
|
|||
---|---|---|---|
#18+
Можно ещё такие конструкции вспомнить www.destructor.de/firebird/charsets.htmYou can also specify the collation with the ORDER BY clause: ORDER BY LASTNAME COLLATE FR_CA, FIRSTNAME COLLATE FR_CA or with the WHERE clause: WHERE LASTNAME COLLATE FR_CA = :lastnametosearch or when searching: WHERE UPPER (LAST_NAME COLLATE SV_SV) = 'PAULSEN'; > для добавления новых предикатов т.е. фактически это разные предикаты есть предикат (T_CS.id collate UNICODE like '%bc%') а есть другой предикат (T_CS.id collate UNICODE_CI like '%bc%') и добавляется неверный предикат.... ... |
|||
:
Нравится:
Не нравится:
|
|||
03.07.2019, 15:15 |
|
FB3, join vs LIKE vs case-sensitivity
|
|||
---|---|---|---|
#18+
Ariochкогда ты сравниваешь signed int 32 и unsigned int 32 ты оба расширяешь до int 64, например с чарсетами и коллейтами должно происходить аналогичное приведение к некоему общему надмножествуС чего это вдруг вы решили, что такое "общее надмножество" существует? Болгарскую кодировку хоть раз видели? А ведь это тоже кирилица. ... |
|||
:
Нравится:
Не нравится:
|
|||
03.07.2019, 15:19 |
|
FB3, join vs LIKE vs case-sensitivity
|
|||
---|---|---|---|
#18+
Ariochесть предикат (T_CS.id collate UNICODE like '%bc%') а есть другой предикат (T_CS.id collate UNICODE_CI like '%bc%') Бинго! Код: sql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17.
... |
|||
:
Нравится:
Не нравится:
|
|||
03.07.2019, 15:22 |
|
FB3, join vs LIKE vs case-sensitivity
|
|||
---|---|---|---|
#18+
Ariochdimitr, на мой взгляд нужно проталкивать вместе с коллейтом когда ты сравниваешь signed int 32 и unsigned int 32 ты оба расширяешь до int 64, например с чарсетами и коллейтами должно происходить аналогичное приведение к некоему общему надмножеству вот здесь ты не прав. Коллейт это в том числе и правила сравнения, нельзя их менять. AriochА почему нельзя? я не сказал что нельзя, я сказал что это криво. Есть хорошие практики, есть плохие. Те кто используют хорошие обычно на такие вещи не попадают. Но это конечно не отменяет что вышеописанный пример является багом. Можешь в трекер бежать ... |
|||
:
Нравится:
Не нравится:
|
|||
03.07.2019, 15:23 |
|
FB3, join vs LIKE vs case-sensitivity
|
|||
---|---|---|---|
#18+
Basil A. Sidorov, В принципе, может и не существовать. Но - UNICODE же... ... |
|||
:
Нравится:
Не нравится:
|
|||
03.07.2019, 15:23 |
|
FB3, join vs LIKE vs case-sensitivity
|
|||
---|---|---|---|
#18+
Симонов ДенисКоллейт это в том числе и правила сравнения, нельзя их менять. Вот именно! И когда оптимизатор проталкивает LIKE с потерей коллейта, а потом берёт дефолтный коллейт у ДРУГОГО столбца, чем был в оригинале - он и теряет исходные "правила сравнения". И отсюда возникает "общий", "идеальный" вопрос, когда вообще вычисляется выражение "field_1 = field_2" - и у этих полей разные чарсеты и/или коллейты, какой чарсет и коллейт в таком случае используется в самой операции сравнения? ... |
|||
:
Нравится:
Не нравится:
|
|||
03.07.2019, 15:29 |
|
FB3, join vs LIKE vs case-sensitivity
|
|||
---|---|---|---|
#18+
AriochВ принципе, может и не существовать. Но - UNICODE же...Юникод не делает сравнимыми русский алфавит ни с немецким, ни даже с болгарским. Хочется сравнивать строки любых языков - не выёживаемся и вообще не указываем сортировку. Будет unicode_binary или как его там. ... |
|||
:
Нравится:
Не нравится:
|
|||
03.07.2019, 15:35 |
|
FB3, join vs LIKE vs case-sensitivity
|
|||
---|---|---|---|
#18+
AriochИ отсюда возникает "общий", "идеальный" вопрос, когда вообще вычисляется выражение "field_1 = field_2" - и у этих полей разные чарсеты и/или коллейты, какой чарсет и коллейт в таком случае используется в самой операции сравнения? любой из них. Хотя мне кажется, надо ошибку кидать. ... |
|||
:
Нравится:
Не нравится:
|
|||
03.07.2019, 15:35 |
|
FB3, join vs LIKE vs case-sensitivity
|
|||
---|---|---|---|
#18+
Условно - это примерно как консистентность БД. Не факт, что данные в БД соответсвуют реальному миру, но они должны быть взаимно-согласованы внутри БД. предикат "LIKE-2" - это функция, созданная на основе двух других функций: сравнения на равенство и LIKE-1 вот внутри самой себя эта процедура создания новой функции-предиката из двух существовавших должна быть внутренне консистентной. т.е. LIKE-2 должна наследовать чарсет и коллейт у обоих функций (сравнения на равенство и LIKE-1). это можно сделать, если возможно определить "надмножество", каким угодно образом, но одинаковым. но если "надмножества" не существует, как Сидоров предлагает, то тогда и выражение "сравнение на равенство" нельзя вычислить вообще? и весь SELECT просто не имеет смысла? Если же это выражение вычисляется - каким угодно образом, может быть неправильным для "реального мира" но внутренне-консистентном внутри модели БД - то значит мы определили что такое "надмножество" и можем его же передать в функцию LIKE-2 ... |
|||
:
Нравится:
Не нравится:
|
|||
03.07.2019, 15:35 |
|
FB3, join vs LIKE vs case-sensitivity
|
|||
---|---|---|---|
#18+
"Магия данных" может приводить к странным результатам и это - не проблема СУБД. Ошибки проектирования приводят к ещё более странным результатам и это, тем более, не проблема СУБД. ... |
|||
:
Нравится:
Не нравится:
|
|||
03.07.2019, 15:37 |
|
FB3, join vs LIKE vs case-sensitivity
|
|||
---|---|---|---|
#18+
Basil A. Sidorovсравнимыми русский алфавит ни с немецким, ни даже с болгарским смотря какое. На больше-меньше вероятно не имеет смысла. А вот на равно/неравно - вполне. это как комплексные числа, упорядочить их нельзя, а сравнить на равенство можно dimitrлюбой из них. Хотя мне кажется, надо ошибку кидать. Любой наугад? в каком порядке relations вошли - "кто первый встал того и тапки" ? Tо есть получается "угадайка" своего рода ? :-( ... |
|||
:
Нравится:
Не нравится:
|
|||
03.07.2019, 15:38 |
|
FB3, join vs LIKE vs case-sensitivity
|
|||
---|---|---|---|
#18+
Basil A. Sidorov"Магия данных" может приводить к странным результатам и это - не проблема СУБД. результат может быть странным, но он должен быть внутренне согласован иначе получаем "тут играем, тут не играем, тут рыбу заворачиваем" ладно, в любом случае, это баг оптимизатора, а до какой степени его можно исправить не отключая функциональность вообще - это "снаружи" не видно. ... |
|||
:
Нравится:
Не нравится:
|
|||
03.07.2019, 15:40 |
|
FB3, join vs LIKE vs case-sensitivity
|
|||
---|---|---|---|
#18+
Ariochсмотря какое. На больше-меньше вероятно не имеет смысла. А вот на равно/неравно - вполне.Бинарное сравнение - да, имеет смысл. Алфавитное - уже "далеко не всегда" или "почти никогда" не имеет смысла. Задав разные правила сравнения по разные стороны знака равенства вы ступили на скользкий путь неопределённого поведения. С моей кочки зрения - человек сам себя перехитрил, но ему очень не хочется признавать собственную ошибку. P.S. Нет, SO я не читал. ... |
|||
:
Нравится:
Не нравится:
|
|||
03.07.2019, 15:43 |
|
FB3, join vs LIKE vs case-sensitivity
|
|||
---|---|---|---|
#18+
AriochЛюбой наугад? в каком порядке relations вошли - "кто первый встал того и тапки" ? Tо есть получается "угадайка" своего рода ? :-( не совсем. Но в общем случае можно сказать что результат не определён. В случае left join как раз понятно кто с кем сравнивается. З.Ы. Запрос в пример надо было переделать на явное указание collate при сравнении такой чтобы он был одинаков с обоих сторон. Тут может потеряться работа с индексом, но это лучше рулить уже через другие вещи, например научить выполнять LEFT JOIN через HASH JOIN ... |
|||
:
Нравится:
Не нравится:
|
|||
03.07.2019, 15:50 |
|
FB3, join vs LIKE vs case-sensitivity
|
|||
---|---|---|---|
#18+
... |
|||
:
Нравится:
Не нравится:
|
|||
03.07.2019, 16:00 |
|
FB3, join vs LIKE vs case-sensitivity
|
|||
---|---|---|---|
#18+
Симонов ДенисЗапрос в пример надо было переделать на явное указание collate при сравнении Тут тоже немножечко криво. Насколько я понимаю логику SQL, то коллейт - это атрибут не операции (сравнения, конкатенация и т.д.), а самих данных. т.е. нельзя написать .....where field_X LIKE collate CCC field_Y или .....where field_X = collate CCC field_Y зато можно писать .....where field_X collate C_1 LIKE field_Y collate C_2 в нашем частном случае, я предполагаю, у строкового литерала вообще нет никакого коллейта, и он его неявно получает от другого операнда. как во многих языках у const X = Y / 1 - единица возьмёт себе тип от Y. но вот если бы в исходном запросе был НЕ ЛИТЕРАЛ, то что делать тогда ? Если бы в исходном запросе было не Код: sql 1.
а например Код: sql 1.
тогда бы collate был уже по обе стороны от LIKE и что делать? ... |
|||
:
Нравится:
Не нравится:
|
|||
03.07.2019, 16:14 |
|
FB3, join vs LIKE vs case-sensitivity
|
|||
---|---|---|---|
#18+
Ariochтогда бы collate был уже по обе стороны от LIKE и что делать?CAST ... |
|||
:
Нравится:
Не нравится:
|
|||
03.07.2019, 16:26 |
|
FB3, join vs LIKE vs case-sensitivity
|
|||
---|---|---|---|
#18+
...и вот к вопросу о литералах... AriochAriochесть предикат (T_CS.id collate UNICODE like '%bc%') а есть другой предикат (T_CS.id collate UNICODE_CI like '%bc%') Бинго! Код: sql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17.
А вот это я уже не млогу объяснить.... Итак, литералы... Database Connection у меня в win1251 Код: sql 1. 2. 3.
Здесь у нас привычный баг, данный только из одной таблицы. Код: sql 1. 2. 3.
Тут мы привычно "прибили гвоздиками" case-insensitive коллейшн к сравнению и получили данные из обеих таблиц. Как и раньше. Осталось "прибить гвоздиком" case-sensitive и не получить ни одной строки, так? Код: sql 1. 2. 3.
Код: plaintext 1. 2. 3.
Оппаньки! Перепроверяем сразу же! Код: sql 1. 2. 3.
.....выборка пустая. Код: plaintext 1. 2.
... |
|||
:
Нравится:
Не нравится:
|
|||
03.07.2019, 16:42 |
|
FB3, join vs LIKE vs case-sensitivity
|
|||
---|---|---|---|
#18+
Arioch, а про условие соединения ты конечно же забыл ... |
|||
:
Нравится:
Не нравится:
|
|||
03.07.2019, 17:09 |
|
FB3, join vs LIKE vs case-sensitivity
|
|||
---|---|---|---|
#18+
Симонов Денис, объясни подробно, как это условие должно было тут влиять и проводить к разным результатам (слева или справа от LIKE): - теоретически, на уровне SQL. - и практически, на уровне реализации. повторяю, что само сравнение(условие соединения) ВСЕГДА выдает true при ЛЮБОМ collation ... |
|||
:
Нравится:
Не нравится:
|
|||
03.07.2019, 17:25 |
|
|
start [/forum/topic.php?all=1&fid=40&tid=1560670]: |
0ms |
get settings: |
8ms |
get forum list: |
13ms |
check forum access: |
3ms |
check topic access: |
3ms |
track hit: |
47ms |
get topic data: |
11ms |
get forum data: |
3ms |
get page messages: |
67ms |
get tp. blocked users: |
1ms |
others: | 11ms |
total: | 167ms |
0 / 0 |