Порожній рядок SQL Server 2008 проти простору

Сьогодні вранці я зіткнувся з чимось трохи дивним і подумав подати це для коментарів.

Хтось може пояснити, чому наступний запит SQL друкує "дорівнює" при запуску проти SQL 2008. Рівень сумісності db встановлено на 100.

if '' = ' '
    print 'equal'
else
    print 'not equal'

І це повертає 0:

select (LEN(' '))

Здається, це автоматичне обрізання простору. Я не маю уявлення, чи так було в попередніх версіях SQL Server, і я більше не маю жодного, щоб навіть перевірити його.

Я зіткнувся з цим, оскільки виробничий запит повертав неправильні результати. Я ніде не можу задокументувати цю поведінку.

Хтось має якусь інформацію з цього приводу?

varchars і рівність є непростими в TSQL. LENФункція каже:

Повертає кількість символів, а не кількість байт, даного рядкового виразу, за винятком порожніх пробілів .

Вам потрібно використовувати, DATALENGTHщоб отримати справжній byteпідрахунок даних, про які йдеться. Якщо у вас є дані Unicode, зверніть увагу, що значення, яке ви отримаєте в цій ситуації, не буде однаковим із довжиною тексту.

print(DATALENGTH(' ')) --1
print(LEN(' '))        --0

Коли справа стосується рівності виразів, два рядки порівнюються для рівності таким чином:

• Отримати коротший рядок
• Прокладка із заготовками, доки довжина не дорівнює довжині довжини
• Порівняйте два

Це середній крок, який призводить до несподіваних результатів - після цього ви ефективно порівнюєте пробіли з пробілами - отже, вони вважаються рівними.

LIKEповодиться краще, ніж =у ситуації "пробілів", оскільки він не виконує заповнення пробілів на шаблоні, який ви намагалися зрівняти:

if '' = ' '
print 'eq'
else
print 'ne'

Дасть, eqпоки:

if '' LIKE ' '
print 'eq'
else
print 'ne'

Дасть ne

Обережно, LIKEхоча: він не симетричний: він розглядає кінцеві пробіли як значущі у шаблоні (RHS), але не вираз відповідності (LHS). Звідси взято наступне :

declare @Space nvarchar(10)
declare @Space2 nvarchar(10)

set @Space = ''
set @Space2 = ' '

if @Space like @Space2
print '@Space Like @Space2'
else
print '@Space Not Like @Space2'

if @Space2 like @Space
print '@Space2 Like @Space'
else
print '@Space2 Not Like @Space'

@Space Not Like @Space2
@Space2 Like @Space

Оператор = T-SQL - це не стільки "дорівнює", скільки "це одне і те ж слово / фраза, відповідно до порівняння контексту виразу", а LEN - "кількість символів у слові / фразі". Жодне зіставлення не розглядає кінцеві пробіли як частину слова / фрази, що передує їм (хоча вони розглядають провідні пробіли як частину рядка, якому вони передують).

Якщо вам потрібно відрізнити "це" від "це", ви не повинні використовувати оператор "це те саме слово або фраза", оскільки "це" і "це" - це одне і те ж слово.

Сприяння шляху = працює - це ідея того, що оператор рівності рядків повинен залежати від вмісту своїх аргументів та від контексту порівняння виразу, але це не повинно залежати від типів аргументів, якщо вони обидва є рядковими типами .

Поняття природної мови "це одне й те саме слово", як правило, недостатньо чітке, щоб його можна було схопити математичним оператором, як =, і в природній мові немає поняття типу рядка. Контекст (тобто співставлення) має значення (і існує в природній мові) і є частиною історії, а додаткові властивості (деякі, які здаються химерними) є частиною визначення = для того, щоб зробити його чітко визначеним у неприродному світі даних.

Що стосується питання типу, ви не хотіли б, щоб слова змінювалися, коли вони зберігаються в різних типах рядків. Наприклад, типи VARCHAR (10), CHAR (10) та CHAR (3) можуть містити зображення слова «кішка», а? = 'cat' повинен дозволити нам вирішити, чи значення будь-якого з цих типів містить слово 'cat' (з питаннями регістру та наголосу, що визначаються порівнянням).

Відповідь на коментар JohnFx:

Див. Розділ Використання даних char та varchar у Books Online. Цитуючи цю сторінку, наголошу на моєму:

Кожне значення даних char та varchar має порівняння. Сортування визначає такі атрибути, як бітові шаблони, що використовуються для представлення кожного символу, правила порівняння та чутливість до регістру чи наголосу.

Я згоден, що це може бути простіше знайти, але це задокументовано.

Варто також зазначити, що семантика SQL, де = має відношення до реальних даних та контексту порівняння (на відміну від чогось про біти, що зберігаються на комп'ютері), є частиною SQL давно. Передумовою СУБД та SQL є вірне представлення даних із реального світу, отже, підтримка збігів за багато років до того, як подібні ідеї (наприклад, CultureInfo) увійшли в сферу мов, подібних до Алголу. Передумовою цих мов (принаймні до недавнього часу) було вирішення проблем в інженерії, а не управління діловими даними. (Останнім часом використання подібних мов у неінженерних програмах, таких як пошук, робить деякі прориви, але Java, C # і так далі все ще борються зі своїми комерційними коріннями.)

На мій погляд, нечесно критикувати SQL за відмінність від "більшості мов програмування". SQL був розроблений для підтримки основи для моделювання бізнес-даних, яка сильно відрізняється від інженерної, тому мова інша (і краще для своєї мети).

Чорт візьми, коли SQL було вперше вказано, деякі мови не мали жодного вбудованого типу рядка. І в деяких мовах досі оператор рівності між рядками взагалі не порівнює дані символів, а порівнює посилання! Мене не здивувало б, якщо через наступні десять років чи два ідея, що == залежить від культури, стає нормою.

Я знайшов цю статтю в блозі, яка описує поведінку та пояснює, чому.

Стандарт SQL вимагає, щоб порівняння рядків фактично заповнювало коротший рядок пробілами. Це призводить до дивовижного результату, що N '' = N '' (порожній рядок дорівнює рядку з одного або декількох пробільних символів) і, загальніше, будь-який рядок дорівнює іншому рядку, якщо вони відрізняються лише кінцевими пробілами. У деяких ситуаціях це може бути проблемою.

Додаткова інформація також доступна в MSKB316626

Нещодавно було подібне запитання, де я розглядав подібну проблему тут

Замість LEN(' '), використовуйте DATALENGTH(' ')- це дає вам правильне значення.

Рішення полягали у використанні LIKEречення, як пояснено в моїй відповіді, та / або включенні другої умови в WHEREпункт для перевірки DATALENGTH.

Прочитайте це питання та посилання там.

Щоб порівняти значення з буквальним пробілом, ви можете також використовувати цей прийом як альтернативу оператору LIKE:

IF ASCII('') = 32 PRINT 'equal' ELSE PRINT 'not equal'

Як відрізнити записи на select за допомогою полів char / varchar на сервері sql: приклад:

declare @mayvar as varchar(10)

set @mayvar = 'data '

select mykey, myfield from mytable where myfield = @mayvar

очікуваний

mykey (int) | myfield (varchar10)

1 | 'дані'

отримані

mykey | myfield

1 | 'дані' 2 | 'дані'

навіть якщо я пишу select mykey, myfield from mytable where myfield = 'data'(без остаточного пробілу), я отримую однакові результати.

як я вирішив? У цьому режимі:

select mykey, myfield
from mytable
where myfield = @mayvar 
and DATALENGTH(isnull(myfield,'')) = DATALENGTH(@mayvar)

і якщо на myfield є індекс, він буде використовуватися в кожному випадку.

Сподіваюся, це буде корисно.

Інший спосіб - повернути його у стан, який має простір. наприклад: замінити пробіл символом, відомим як _

if REPLACE('hello',' ','_') = REPLACE('hello ',' ','_')
    print 'equal'
else
    print 'not equal'

повертає: не дорівнює

Не ідеально, і, мабуть, повільно, але це ще один швидкий шлях вперед, коли потрібно швидко.

Іноді доводиться мати справу з пробілами в даних, з будь-якими іншими символами або без них, хоча ідея використання Null є кращою - але не завжди придатною для використання. Я натрапив на описану ситуацію і вирішив її таким чином:

... where ('>' + @space + '<') <> ('>' + @space2 + '<')

Звичайно, ви не зробите цього для великого обсягу даних, але це працює швидко і просто для кількох сотень рядків ...