ReSQL.ru
     
powered by simpleCommunicator - 2.0.51     © 2025 Programmizd 02
Мобильная версия    Контакт    Правила    FAQ    Помощь
Доб. в избранное | Игнор. тему | Прикреп. тему | Пометить прочит. / непрочит. | Фильтр
Форумы / Firebird, InterBase [игнор отключен] [закрыт для гостей] / FB3, join vs LIKE vs case-sensitivity
18 сообщений из 43, страница 2 из 2
  2  все
FB3, join vs LIKE vs case-sensitivity
    #39833372
Фотография Симонов Денис
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Симонов Денис
Участник
Ariochdimitr,

на мой взгляд нужно проталкивать вместе с коллейтом

когда ты сравниваешь signed int 32 и unsigned int 32 ты оба расширяешь до int 64, например

с чарсетами и коллейтами должно происходить аналогичное приведение к некоему общему надмножеству


вот здесь ты не прав. Коллейт это в том числе и правила сравнения, нельзя их менять.

AriochА почему нельзя?

я не сказал что нельзя, я сказал что это криво. Есть хорошие практики, есть плохие. Те кто используют хорошие обычно на такие вещи не попадают.

Но это конечно не отменяет что вышеописанный пример является багом. Можешь в трекер бежать
...
Рейтинг: 0 / 0
03.07.2019, 15:23
| Ответить | Цитировать | Написать  
FB3, join vs LIKE vs case-sensitivity
    #39833373
Arioch
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Arioch
Участник
Basil A. Sidorov,

В принципе, может и не существовать. Но - UNICODE же...
...
Рейтинг: 0 / 0
03.07.2019, 15:23
| Ответить | Цитировать | Написать  
FB3, join vs LIKE vs case-sensitivity
    #39833379
Arioch
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Arioch
Участник
Симонов ДенисКоллейт это в том числе и правила сравнения, нельзя их менять.

Вот именно! И когда оптимизатор проталкивает LIKE с потерей коллейта, а потом берёт дефолтный коллейт у ДРУГОГО столбца, чем был в оригинале - он и теряет исходные "правила сравнения".

И отсюда возникает "общий", "идеальный" вопрос, когда вообще вычисляется выражение "field_1 = field_2" - и у этих полей разные чарсеты и/или коллейты, какой чарсет и коллейт в таком случае используется в самой операции сравнения?
...
Рейтинг: 0 / 0
03.07.2019, 15:29
| Ответить | Цитировать | Написать  
FB3, join vs LIKE vs case-sensitivity
    #39833381
Basil A. Sidorov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Basil A. Sidorov
Участник
AriochВ принципе, может и не существовать. Но - UNICODE же...Юникод не делает сравнимыми русский алфавит ни с немецким, ни даже с болгарским.
Хочется сравнивать строки любых языков - не выёживаемся и вообще не указываем сортировку. Будет unicode_binary или как его там.
...
Рейтинг: 0 / 0
03.07.2019, 15:35
| Ответить | Цитировать | Написать  
FB3, join vs LIKE vs case-sensitivity
    #39833382
dimitr
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
dimitr
Участник
AriochИ отсюда возникает "общий", "идеальный" вопрос, когда вообще вычисляется выражение "field_1 = field_2" - и у этих полей разные чарсеты и/или коллейты, какой чарсет и коллейт в таком случае используется в самой операции сравнения?
любой из них. Хотя мне кажется, надо ошибку кидать.
...
Рейтинг: 0 / 0
03.07.2019, 15:35
| Ответить | Цитировать | Написать  
FB3, join vs LIKE vs case-sensitivity
    #39833384
Arioch
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Arioch
Участник
Условно - это примерно как консистентность БД.
Не факт, что данные в БД соответсвуют реальному миру, но они должны быть взаимно-согласованы внутри БД.

предикат "LIKE-2" - это функция, созданная на основе двух других функций: сравнения на равенство и LIKE-1
вот внутри самой себя эта процедура создания новой функции-предиката из двух существовавших должна быть внутренне консистентной.

т.е. LIKE-2 должна наследовать чарсет и коллейт у обоих функций (сравнения на равенство и LIKE-1).

это можно сделать, если возможно определить "надмножество", каким угодно образом, но одинаковым.

но если "надмножества" не существует, как Сидоров предлагает, то тогда и выражение "сравнение на равенство" нельзя вычислить вообще? и весь SELECT просто не имеет смысла?

Если же это выражение вычисляется - каким угодно образом, может быть неправильным для "реального мира" но внутренне-консистентном внутри модели БД - то значит мы определили что такое "надмножество" и можем его же передать в функцию LIKE-2
...
Рейтинг: 0 / 0
03.07.2019, 15:35
| Ответить | Цитировать | Написать  
FB3, join vs LIKE vs case-sensitivity
    #39833385
Basil A. Sidorov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Basil A. Sidorov
Участник
"Магия данных" может приводить к странным результатам и это - не проблема СУБД.
Ошибки проектирования приводят к ещё более странным результатам и это, тем более, не проблема СУБД.
...
Рейтинг: 0 / 0
03.07.2019, 15:37
| Ответить | Цитировать | Написать  
FB3, join vs LIKE vs case-sensitivity
    #39833386
Arioch
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Arioch
Участник
Basil A. Sidorovсравнимыми русский алфавит ни с немецким, ни даже с болгарским

смотря какое. На больше-меньше вероятно не имеет смысла. А вот на равно/неравно - вполне.

это как комплексные числа, упорядочить их нельзя, а сравнить на равенство можно


dimitrлюбой из них. Хотя мне кажется, надо ошибку кидать.

Любой наугад? в каком порядке relations вошли - "кто первый встал того и тапки" ?
Tо есть получается "угадайка" своего рода ? :-(
...
Рейтинг: 0 / 0
03.07.2019, 15:38
| Ответить | Цитировать | Написать  
FB3, join vs LIKE vs case-sensitivity
    #39833388
Arioch
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Arioch
Участник
Basil A. Sidorov"Магия данных" может приводить к странным результатам и это - не проблема СУБД.

результат может быть странным, но он должен быть внутренне согласован
иначе получаем "тут играем, тут не играем, тут рыбу заворачиваем"

ладно, в любом случае, это баг оптимизатора, а до какой степени его можно исправить не отключая функциональность вообще - это "снаружи" не видно.
...
Рейтинг: 0 / 0
03.07.2019, 15:40
| Ответить | Цитировать | Написать  
FB3, join vs LIKE vs case-sensitivity
    #39833392
Basil A. Sidorov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Basil A. Sidorov
Участник
Ariochсмотря какое. На больше-меньше вероятно не имеет смысла. А вот на равно/неравно - вполне.Бинарное сравнение - да, имеет смысл. Алфавитное - уже "далеко не всегда" или "почти никогда" не имеет смысла.
Задав разные правила сравнения по разные стороны знака равенства вы ступили на скользкий путь неопределённого поведения.
С моей кочки зрения - человек сам себя перехитрил, но ему очень не хочется признавать собственную ошибку.

P.S.
Нет, SO я не читал.
...
Рейтинг: 0 / 0
03.07.2019, 15:43
| Ответить | Цитировать | Написать  
FB3, join vs LIKE vs case-sensitivity
    #39833396
Фотография Симонов Денис
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Симонов Денис
Участник
AriochЛюбой наугад? в каком порядке relations вошли - "кто первый встал того и тапки" ?
Tо есть получается "угадайка" своего рода ? :-(

не совсем. Но в общем случае можно сказать что результат не определён.
В случае left join как раз понятно кто с кем сравнивается.

З.Ы. Запрос в пример надо было переделать на явное указание collate при сравнении такой чтобы он был одинаков с обоих сторон. Тут может потеряться работа с индексом, но это лучше рулить уже через другие вещи, например научить выполнять LEFT JOIN через HASH JOIN
...
Рейтинг: 0 / 0
03.07.2019, 15:50
| Ответить | Цитировать | Написать  
FB3, join vs LIKE vs case-sensitivity
    #39833403
Arioch
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Arioch
Участник
http://tracker.firebirdsql.org/browse/CORE-6094
...
Рейтинг: 0 / 0
03.07.2019, 16:00
| Ответить | Цитировать | Написать  
FB3, join vs LIKE vs case-sensitivity
    #39833415
Arioch
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Arioch
Участник
Симонов ДенисЗапрос в пример надо было переделать на явное указание 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.
WHERE MAIN_TABLE.code LIKE '%abc%'


а например
Код: sql
1.
WHERE MAIN_TABLE.code LIKE (select singleton_value from dictionary where ...)


тогда бы collate был уже по обе стороны от LIKE и что делать?
...
Рейтинг: 0 / 0
03.07.2019, 16:14
| Ответить | Цитировать | Написать  
FB3, join vs LIKE vs case-sensitivity
    #39833425
hvlad
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
hvlad
Участник
Ariochтогда бы collate был уже по обе стороны от LIKE и что делать?CAST
...
Рейтинг: 0 / 0
03.07.2019, 16:26
| Ответить | Цитировать | Написать  
FB3, join vs LIKE vs case-sensitivity
    #39833441
Arioch
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Arioch
Участник
...и вот к вопросу о литералах...

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.
select * from T_CI
 left join T_CS on T_CS.id = T_CI.id
 where T_CI.id like '%bc%'

-- ERROR: data ~ NULL

select * from T_CI
 left join T_CS on T_CS.id = T_CI.id
 where T_CI.id collate unicode like '%bc%'

-- OK: NULL ~ NULL

select * from T_CI
 left join T_CS on T_CS.id = T_CI.id
 where T_CI.id collate unicode_ci like '%bc%'

-- OK: data ~ data



А вот это я уже не млогу объяснить....

Итак, литералы... Database Connection у меня в win1251

Код: sql
1.
2.
3.
select * from T_CI
 left join T_CS on T_CS.id = T_CI.id
 where T_CI.id like _UTF8 '%bc%'  --collate unicode



Здесь у нас привычный баг, данный только из одной таблицы.

Код: sql
1.
2.
3.
select * from T_CI
 left join T_CS on T_CS.id = T_CI.id
 where T_CI.id like _UTF8 '%bc%' collate unicode_ci



Тут мы привычно "прибили гвоздиками" case-insensitive коллейшн к сравнению и получили данные из обеих таблиц. Как и раньше.

Осталось "прибить гвоздиком" case-sensitive и не получить ни одной строки, так?

Код: sql
1.
2.
3.
select * from T_CI
 left join T_CS on T_CS.id = T_CI.id
where T_CI.id like _UTF8 '%bc%' collate unicode



Код: plaintext
1.
2.
3.
PLAN JOIN (T_CI NATURAL, T_CS INDEX (RDB$PRIMARY3))

ID	PAYLOAD	ID1	PAYLOAD1
ABCD	22	ABCD	-100

Оппаньки!


Перепроверяем сразу же!
Код: sql
1.
2.
3.
select * from T_CI
 left join T_CS on T_CS.id = T_CI.id
 where T_CI.id collate unicode like _UTF8 '%bc%' --collate unicode



.....выборка пустая.

Код: plaintext
1.
2.
PLAN JOIN (T_CI NATURAL, T_CS INDEX (RDB$PRIMARY3))

ID	PAYLOAD	ID1	PAYLOAD1
...
Рейтинг: 0 / 0
03.07.2019, 16:42
| Ответить | Цитировать | Написать  
FB3, join vs LIKE vs case-sensitivity
    #39833451
Фотография Симонов Денис
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Симонов Денис
Участник
Arioch,

а про условие соединения ты конечно же забыл
...
Рейтинг: 0 / 0
03.07.2019, 17:09
| Ответить | Цитировать | Написать  
FB3, join vs LIKE vs case-sensitivity
    #39833461
Arioch
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Arioch
Участник
Симонов Денис,

объясни подробно, как это условие должно было тут влиять и проводить к разным результатам (слева или справа от LIKE):

- теоретически, на уровне SQL.
- и практически, на уровне реализации.

повторяю, что само сравнение(условие соединения) ВСЕГДА выдает true при ЛЮБОМ collation
...
Рейтинг: 0 / 0
03.07.2019, 17:25
| Ответить | Цитировать | Написать  
FB3, join vs LIKE vs case-sensitivity
    #39833465
Мимопроходящий
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Мимопроходящий
Участник
а обернуть эту хрень в SELECT ... FROM (SELECT ...) ?
с выносом фильтрации "наружу".
Posted via ActualForum NNTP Server 1.5
...
Рейтинг: 0 / 0
03.07.2019, 17:34
| Ответить | Цитировать | Написать  
18 сообщений из 43, страница 2 из 2
  2  все
Форумы / Firebird, InterBase [игнор отключен] [закрыт для гостей] / FB3, join vs LIKE vs case-sensitivity
Целевая тема:
Создать новую тему:
Автор:
Закрыть
Цитировать
Найденые пользователи ...
Разблокировать пользователей ...
Читали тему (0):
Читали форум (0):
Пользователи онлайн (0):
Польз. соглашение
NoSQL.ru       Новости, Чат       Фотоальбом: Участники, Встречи
Закрыть
start [/forum/topic.php?fid=40&msg=39833415&tid=1560670]:
 0ms
get settings:
 7ms
get forum list:
 11ms
check forum access:
 2ms
check topic access:
 2ms
track hit:
 140ms
get topic data:
 11ms
get forum data:
 3ms
get page messages:
 55ms
get tp. blocked users:
 1ms
others: 14ms
total:  246ms
созд. / загр.: 246ms
x
x
Закрыть


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