like ot not to like

Уж вроде привык, ан нет, опять билли меня удивил. Я даже оценку давать не буду, изложу факты (о, боже, вы опять сказали fuck!).

База данных под управлением MS SQL Server 2000. В базе табличка, в табличке поле типа GUID. Этот тип данных применяется среди прочего при репликации.

При выборке из таблицы, значения этого поля выглядят так:
{57EEFC0A-0CED-4476-9E4D-ADA821DCEBB2}

В табличке надо найти запись, причем этот гуид - ключ и искать надо по нему.
Запрос вроде такого:
select * from earch.viewSearchProjects where
ProjectID = '{57EEFC0A-0CED-4476-9E4D-ADA821DCEBB2}'
находит запись, а такой:
select * from earch.viewSearchProjects where
ProjectID like '{57EEFC0A-0CED-4476-9E4D-ADA821DCEBB2}'
не находит. Уже интересно.
Зато находит такой:
select * from earch.viewSearchProjects where
ProjectID like '57EEFC0A-0CED-4476-9E4D-ADA821DCEBB2'
Убраны фигурные скобки, если не заметили.

С другими типами полей таких странностей не наблюдается, все как положено.
Закрадывается мысль, проверяю:
select * from earch.viewSearchProjects where
ProjectID = '57EEFC0A-0CED-4476-9E4D-ADA821DCEBB2'
работает. И чего-ж ему не работать, когда чистые данные примерно так и выглядят (еще бы минусы убрать и будет самое оно - 128-битное число).

И как это понимать? Как расценивать необходимость убирать часть данных (а эти данные нам вернула база по запросу на выборку) перед использованием значения поля в других запросах? Причем для некоторых типов данных, не для всех.
Или надо так спросить - и как понимать самоуправство СУБД, которая к данным добавляет свои блядские скобочки?

Ну вот, не удержался от оценок.

Ну и как вот жить с такими заморочками? Если у вас поле типа Х, вы должны обработь данные перед любым использованием по алгоритму У, а если... а если ... пля. Прав Лебедев тыщу раз. Когда матерится. Уебаны и есть.