Чи краще в MySQL завжди дозволяти нулі, якщо ви не знаєте, що це поле потрібно, або завжди використовувати, Not Nullякщо ви не знаєте, що поле буде містити нулі? Або це не має значення?
Я знаю, що в деяких СУБД вони кажуть використовувати Not Nullякомога більше, оскільки для дозволу нулів потрібен додатковий біт (або байт?) На запис, щоб зберігати стан Null.
Відповіді:
У більшості баз даних NOT NULLстовпець буде більш ефективним щодо збережених даних з причини, яку ви заявляєте, а також більш ефективним для запитів та індексів, тому, якщо ви не хочете дозволити NULLs у стовпці, ви повинні явно заборонити їх.
Буде незначне значення для продуктивності, оскільки додаткові NOT NULLобмеження потенційно потрібно перевірити для кожного рядка, на який ви впливаєте, будь-яким INSERT або UPDATE, але оскільки більшість баз даних є відносно легкими для запису та важкими для читання, це, мабуть, не викликає занепокоєння (мало додатковий час, навряд чи взагалі буде помітний, оскільки це операція, пов'язана з процесором, де решта операцій з вставкою / оновленням буде пов'язана з IO і, таким чином, набагато більш значним вирізом), і це дає вам "безкоштовно "перевірка даних, щоб ваш код (або код інших людей) не міг випадково поставити NULL, якщо інший код їх не очікує, і тому може дати неправильні результати в їх присутності.
Редагувати: Як Петр зазначає у своєму коментарі, вищесказане - це загальний характер і, можливо, не відповідає дійсності для всіх DMBS, хоча я впевнений, що це стосується mysql та mssql. Інші ускладнення в цій області можуть включати такі функції, як розріджені таблиці (як, наприклад, впроваджений MSSQL 2008), які змінять динаміку продуктивності (не) обнулених стовпців.
Ви повинні дозволити вашій схемі розробки та вимогам програми керувати цим рішенням. Відмінності в продуктивності, мабуть, не помітні в будь-якому випадку в більшості випадків.
NULLякщо і тільки якщоNULLзначення має інтерпретацію для речі, яку ви моделюєте.