SQL: порожній рядок та значення NULL

Я знаю, що ця тема трохи суперечлива, і в Інтернеті пливе багато різноманітних статей / думок. На жаль, більшість з них припускають, що людина не знає, в чому різниця між NULL і порожнім рядком. Таким чином вони розповідають історії про дивовижні результати приєднаннях / агрегатах і, як правило, роблять трохи більш досконалі уроки SQL. Роблячи це, вони абсолютно пропускають всю суть і тому для мене марні. Тож сподіваємось, що це запитання та всі відповіді перемістять тему трохи вперед.

Припустимо, у мене є таблиця з особистими даними (ім’я, народження тощо), де один із стовпців - це адреса електронної пошти з типом varchar. Ми припускаємо, що чомусь деякі люди можуть не захотіти надати адресу електронної пошти. Під час вставлення таких даних (без електронної пошти) у таблицю є два доступні варіанти: встановити комірку на NULL або встановити порожній рядок (''). Припустимо, що я знаю про всі технічні наслідки вибору одного рішення над іншим, і я можу створити правильні SQL запити для будь-якого сценарію. Проблема навіть тоді, коли обидва значення різняться на технічному рівні, на логічному рівні вони однакові. Подивившись на NULL і "" Я прийшов до єдиного висновку: я не знаю електронної адреси хлопця. Крім того, як би я не намагався, Мені не вдалося надіслати електронний лист, використовуючи NULL або порожню рядок, тому, мабуть, більшість SMTP-серверів там згодні з моєю логікою. Тому я схильний використовувати NULL там, де я не знаю значення і вважаю порожню рядок поганою справою.

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

1. я маю рацію припускати, що використання порожнього рядка для невідомого значення змушує базу даних "брехати" про факти? Якщо бути більш точним: використовуючи уявлення SQL про те, що є значенням, а що ні, я можу прийти до висновку: у нас є електронна адреса, лише з'ясувавши, що вона не є нульовою. Але згодом, намагаючись надіслати електронний лист, я прийду до суперечливого висновку: ні, у нас немає електронної адреси, що @! # $ База даних, мабуть, бреше!

2. Чи є логічний сценарій, коли порожній рядок '' може бути таким хорошим носієм важливої ​​інформації (окрім значення та без значення), який було б складно / неефективно зберігати будь-яким іншим способом (наприклад, додатковим стовпцем). Я бачив багато повідомлень, які стверджують, що іноді добре використовувати порожню рядок разом з реальними значеннями та NULL, але поки що не бачив сценарій, який був би логічним (з точки зору дизайну SQL / DB).

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

Я б сказав, що NULLце правильний вибір для "немає адреси електронної пошти". Є багато "недійсних" адрес електронної пошти, а "" (порожній рядок) - лише одна. Наприклад, "foo" не є дійсною адресою електронної пошти, "a @ b @ c" недійсна тощо. Тому лише тому, що "" не є дійсною адресою електронної пошти, це не є підставою використовувати її як значення "немає адреси електронної пошти".

Я думаю, ти маєш рацію сказати, що "" не є правильним способом сказати "я не маю значення для цього стовпця". "" - значення.

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

Погоджуючись з вищезазначеними коментарями, я б додав цей аргумент як основну мотивацію:

1. Кожному програмісту, який дивиться на базу даних, очевидно, що поле з позначкою NULL - це необов'язкове поле. (тобто запис не вимагає даних для цього стовпця)
2. Якщо ви позначаєте поле НЕ НУЛЬНИЙ, будь-який програміст повинен інтуїтивно вважати, що це обов'язкове поле.
3. У полі, яке дозволяє нулі, програмістам слід очікувати, що вони побачать нулі, а не порожні рядки.

Для самостійного документування інтуїтивного кодування використовуйте NULL замість порожніх рядків.

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

Ось посилання на пункти, які ви можете розглянути: https://stackoverflow.com/questions/405909/null-vs-empty-when-dealing-with-user-input/405945#405945

--- відредаговано (У відповідь на коментар Томаса) ---

Бази даних не живуть без додатків, які ними користуються. Визначення NULL або "" не мають значення, якщо програма не може використовувати його належним чином.

Розглянемо один приклад, коли користувач заповнює форму LONG і натискає клавішу Enter, яка надсилатиме постійний запит на сервер. Він міг бути посеред введення електронної пошти. Найімовірніше, ви хочете зберігати все, що він має, у полі електронної пошти, щоб пізніше він міг закінчити це. Що робити, якщо він ввів лише одного персонажа? Що робити, якщо він ввів один символ і потім видалив його? Коли електронна пошта не потрібна, іноді користувачі хочуть її видалити: найпростіший спосіб просто очистити поле. Також у випадку, коли електронна пошта не потрібна, варто перевірити її перед надсиланням.

Ще один приклад: користувач надає електронну пошту як spamto @ [bigcompany] .com - у цьому випадку немає необхідності надсилати електронну пошту, навіть якщо вона існує та є дійсною (і може навіть існувати). Надсилання одного такого, можливо, дешевого, але якщо для щоденних підписок є 10K користувачів з такими електронними листами, то така перевірка може заощадити багато часу.

Я думаю, що відповідь Діна Гардінга висвітлює це дуже добре. Це означає, що я хотів би зазначити, що, говорячи про NULL та порожні рядки на рівні БД, ви повинні подумати про ваші інші типи даних. Чи зберігатимете ви мінімальну дату, коли дата не вказана? або -1, коли не вводиться int? Збереження значення, коли у вас немає значення, означає, що вам доведеться відслідковувати цілий спектр не значень. Принаймні один для кожного типу даних (можливо більше, оскільки ви отримуєте випадки, коли -1 - фактичне значення, тому вам потрібно мати альтернативу тощо). Якщо вам потрібно / хочете зробити щось "вигадливе" на рівні програми, це одне, але їх немає необхідності забруднювати ваші дані.

На жаль, Oracle переплутав подання рядка VARCHAR довжиною нульової із поданням NULL. Обидва вони представлені внутрішньо одним байтом зі значенням нуль. Це ускладнює дискусію набагато складніше.

Дуже багато плутанини навколо NULL зосереджується навколо тризначної логіки . Розглянемо наступний псевдокод:

if ZIPCODE = NULL
    print "ZIPCODE is NULL"
else if ZIPCODE <> NULL
    print "ZIPCODE is not NULL"
else print "Something unknown has happened"

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

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

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

Також пам’ятайте, що навіть якщо ви повністю уникаєте NULLS у збережених даних (шоста нормальна форма), якщо ви виконайте будь-які зовнішні з'єднання, вам все одно доведеться впоратися з NULLS.

Використовуйте Null.

Немає сенсу зберігати значення '', коли просто зробимо поле в таблиці нульовим. Це також робить запити більш очевидними.

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

1. SELECT * FROM Users WHERE email_address != ''

2. SELECT * FROM Users WHERE email_address IS NOT NULL

3. SELECT * FROM Users WHERE email_address != '' and email_address IS NOT NULL

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

У випадку з адресою електронної пошти у формі, яка є необов’язковою, вона повинна бути відображена і в таблиці. У SQL це нульове поле, а це означає, що воно не відоме.

Я не можу думати про якусь розумну ділову цінність для зберігання порожнього рядка в таблиці, крім просто поганого дизайну. Це як зберігання значення рядка "NULL" або "BLANK", а розробники припускають, що це нульовий або порожній рядок. Для мене це поганий дизайн. Навіщо зберігати це, коли є NULL ??

Просто використовуйте NULL, і ви зробите всіх трохи щасливішими.

БІЛЬШЕ ІНФОРМАЦІЇ:

SQL використовує три цінні логічні системи: True, False та Unknown.

Для кращого та детальнішого пояснення я рекомендую розробникам прочитати: SQL Queries - понад TRUE та FALSE .

для конкретного технічного питання питання не є нульовим проти порожнього рядка, це помилка перевірки . Порожня рядок не є дійсною адресою електронної пошти!

на філософське запитання відповідь схожа: підтвердіть свої дані. Якщо порожній рядок є дійсним значенням для відповідного поля, тоді очікуйте його та кодуйте його; якщо ні, використовуйте null.

Порожній рядок був би вагомим вкладом для відповіді на питання: Що мім сказав жирафі?

Я міг би придумати причину виникнення NULL та порожнього рядка:

• У вас є дійсні адреси електронної пошти: me@example.com
• У вас немає жодного (і, мабуть, слід попросити його): NULL
• Ви знаєте, що ця особа не має електронної адреси: Empty String.

Однак я б не рекомендував цього і використовував окреме поле для того, щоб запитати, чи знаєте ви, що жодне не існує.

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

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

Ну в основному на логічному рівні немає різниці між значенням "недійсне" та "відсутність вводу користувача", більшість часу вони просто "особливі випадки". Випадок помилки.

Маючи null займає додатковий простір: ceil (column_with_null / 8) у байтах / на рядок.

Порожня клітинка та null - це спосіб позначити щось не так / має бути за замовчуванням. Навіщо вам потрібно 2 "неправильних" стану? Навіщо використовувати NULL, якщо вони займають додатковий простір і означають точно так само, як порожні рядки? Це просто призведе до плутанини та надмірності, коли у вас є дві речі, що означають (це може означати) абсолютно однаково, легко забути, що ви повинні використовувати NULLs замість порожніх рядків (якщо, наприклад, користувач заборонив деякі поля).

І ваші дані можуть стати безладом. У ідеальному світі ви б сказали, що "дані будуть завжди правильними, і я пам’ятаю" ... але коли люди повинні працювати в команді, а не всі точно на вашому рівні, не рідкість бачити, де (аа. xx <> '' І bb.zz НЕ НУЛЬНИЙ)

Тому замість того, щоб виправляти членів моєї команди через день, я просто виконую просте правило. Ні нульових значень, НІКОЛИ!

Підрахунок значень NON-NULL швидше ... Просте запитання - для чого вам це потрібно?

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

У програмі мені не подобається нуль / нічого. Є кілька винятків, але вони є саме такими. І ці винятки - це лише погані реалізації.

Отже, якщо користувач не помістив повідомлення в електронній пошті, він повинен мати щось, що визначає, чи це дійсно, чи ні. Якщо порожнє повідомлення електронної пошти добре, то він відображає порожній рядок. Якщо користувач не вказав електронний лист і це порушує правило, об’єкт повинен вказати це.

Ідея нуля, яка має значення, - це стара школа, і це те, про що мають працювати сучасні програмісти.

Навіть у дизайні БД чому поле електронної пошти не може дозволити нулі та мати рядок нульової довжини та інше поле, яке вказує, чи користувач щось вводить? Це один біт, який потрібно запитати в СУБД? На мою думку, БД не повинен обробляти ні логіку бізнесу, ні логіку відображення. Він не був побудований для цього і, таким чином, робить дуже погану роботу з цим.

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

Коли я переглядаю дані, що відображаються в таблиці (як, наприклад, в SQL Server Management Studio), я можу краще розрізнити відсутнє значення, якщо воно говорить про NULL, а фон має інший колір.

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

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