Невозможно найти строку в базе данных по UUID RAW (32)

Question

У меня есть следующая таблица:

create table Mike_Test
( Id          raw(32)      default sys_guid() not null primary key,
  Value        varchar2(80) not null unique
);

Теперь я вставлю в эту таблицу:

INSERT INTO Mike_Test (VALUE) VALUES ('Blah');

Я могу подтвердить, что там есть новая строка:

select * from Mike_Test;

И я вижу:

08364fc81419429d83c9bcedb24a9a57    Blah

Теперь я пытаюсь выбрать эту строку с помощью:

select * from Mike_Test WHERE ID='08364fc81419429d83c9bcedb24a9a57';

Однако я получаю ноль строк и ноль ошибок. Что я делаю не так?

Answer 1

Это тип данных RAW, вы должны сделать запрос следующим образом:

select .... where id=hextoraw('08364fc81419429d83c9bcedb24a9a57') ....

Answer 2

Я думаю, вам может понадобиться использовать функцию HEXTORAW для вашего значения ID.Эта функция преобразует шестнадцатеричную строку в соответствующее значение RAW.

Другими словами, ваш запрос должен выглядеть следующим образом:

select * from Mike_Test WHERE ID=HEXTORAW('08364fc81419429d83c9bcedb24a9a57');

Answer 3

Хех, я еще немного поиграл, и ответ довольно глупый. Кажется, что Oracle неявно приведёт строку к GUID (как и ожидал бы обычный человек), но приведения учитывает регистр! Что имеет абсолютно нулевой смысл, если вы анализируете шестнадцатеричные числа, а регистр не относится к вашей базе. Причина, по которой это меня оттолкнуло, заключалась в том, что я использовал Aqua Data Studio, которая по какой-то причине отображает GUID в нижнем регистре.

Следующее из SQLPlus, который правильно обрабатывает вывод:

SQL> select * from Mike_Test;

ID
--------------------------------
VALUE
--------------------------------------------------------------------------------
4FBD50C370BC4A7F85E3DF034D120930
Blah


SQL> select * from Mike_Test WHERE ID='4fbd50c370bc4a7f85e3df034d120930';

no rows selected

SQL> select * from Mike_Test WHERE ID='4FBD50C370BC4A7F85E3DF034D120930';

ID
--------------------------------
VALUE
--------------------------------------------------------------------------------
4FBD50C370BC4A7F85E3DF034D120930
Blah

Оракул становится все глупее с каждым днем, клянусь.

Answer 4

Добавление к моему ответу (я не хотел редактировать свой первоначальный ответ, так как это такой касательный):

Существуют огромные различия в производительности между неявным приведением, которое я пытался выполнить, и рекомендуемым подходом HEXTORAW. План запроса для неявного приведения выглядит примерно так:

SELECT STATEMENT    3.0 3   37877   1   52  3                   ALL_ROWS                                            
TABLE ACCESS (FULL) 3.0 3   37877   1   52  1   TPMDBO  MIKE_TEST   FULL    TABLE       1

И HEXTORAW это:

SELECT STATEMENT    1.0 1   15463   1   52  1                   ALL_ROWS                                            
TABLE ACCESS (BY INDEX ROWID)   1.0 1   15463   1   52  1   TPMDBO  MIKE_TEST   BY INDEX ROWID  TABLE       1                                       
INDEX (UNIQUE SCAN) 1.0 1   8171    1       1   TPMDBO  SYS_C007969 UNIQUE SCAN INDEX (UNIQUE)                  1                           

Как видите, подход HEXTORAW ударит по первичному ключевому индексу в таблице. Это связано с тем, что неявное преобразование будет учитывать тип «string» правого операнда (указанный мной GUID) и преобразовывать все GUID в базе данных в строки. Определенно, что-то рассмотреть.