Помірна практика, що не стосується іноземних ключів?

Скажімо, у вас є таблиця Замовлення із іноземним ключем до ідентифікатора клієнта. Тепер, припустимо, ви хочете додати замовлення без ідентифікатора клієнта, (чи має бути це можливо - це інше питання), вам доведеться зробити зовнішній ключ NULL ... Це погана практика чи ви б краще працювали з таблицею посилань між Замовлення та замовники? Хоча відношення є 1 до n, таблиця посилань зробить це n до n. З іншого боку, із таблицею посилань я більше не маю цих НУЛІВ ...

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

(У моєму випадку це не Замовлення та Клієнт).

РЕДАКТ: Що з непризначеним Клієнтом для посилання?

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

На бічній записці; за допомогою таблиці посилань не обов'язково робити це n до n, якщо ви в таблиці посилань використовуєте зовнішній ключ, який вказує на таблицю ваших замовлень як основний ключ у цій таблиці посилань, зв’язок все ще становить 1..n. У цій таблиці посилань може бути лише один запис у кожному посиланні.

Ні З Nullable FK не буває нічого поганого. Це звичайно, коли сутність, на яку вказує FK, перебуває у відносинах (нуль або один) до (1 або багато) з таблицею, на яку посилається первинний ключ.

Прикладом може бути, якщо у вас були як фізична адреса, так і атрибут (стовпець) адреси електронної пошти (таблиця) у таблиці, з FKs до таблиці адрес. Ви можете зробити фізичну адресу зведеною для оброблення, коли суб'єкт господарювання має лише поштове вікно (поштова адреса), а поштову адресу - зведеною для обробки, коли поштова адреса збігається з фізичною адресою (чи ні).

Зменшувані стовпці можуть бути від 1NF до 5NF, але не в 6NF відповідно до того, що я прочитав.

Тільки якщо ти краще знаєш, ніж Кріс Дата, "що означає перша нормальна форма насправді". Якщо x і y обидва є нульовими, і справді в якомусь рядку x і y є обома null, то WHERE x=yце не поступається true. Це доводить поза розумним сумнівом, що null не є величиною (тому що будь-яка реальна цінність завжди сама собі рівна). А оскільки RM прописує, що "повинно бути значення у кожній комірці таблиці", будь-яка річ, яка, можливо, містить нулі, не є реляційною річчю, і тому питання про 1NF навіть не виникає.

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

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

Але на практиці це дуже практично.

Тільки якщо ви не застраховані від головних болів, які вони зазвичай викликають у всьому іншому світі. Одним із таких головних болів (і це лише незначний, порівняно з іншими nullфеноменами) є той факт, що WHERE x=yв SQL насправді означаєWHERE x is not null and y is not null and x=y , але що більшість програмістів просто не знають цього факту і просто читають його. Іноді без жодної шкоди, інший раз ні.

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

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

Необов'язкові відносини, безумовно, можливі в реляційній моделі.

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

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

Використання NULL було б хорошим способом очищення неповних замовлень:

SELECT * FROM `orders`
WHERE `started_time` < (UNIX_TIMESTAMP() + 900) AND `customer_id` IS NULL

Вищенаведені покази замовлень старше 15 хвилин без відповідного ідентифікатора клієнта.

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

Зазвичай така ситуація виникає у веб-додатках, де докладно деталізується замовлення, перш ніж клієнт визначить, хто він / вона. І в таких ситуаціях замовлення зберігається в стані сервера або в файлі cookie до тих пір, поки не буде надано весь необхідний стан для повного замовлення, в який момент замовлення зберігається в базі даних.

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

Ви завжди можете додати до таблиці клієнтів штучний рядок, наприклад Id = -1 та CustomerName = "Невідомий", а потім у випадках, коли ви зазвичай встановлюєте CustomerId у Order NULL, це -1.

Це дозволяє вам не мати змінних ФК, але все-таки належним чином представляти брак даних (і позбавить вас від користувачів, що не входять у рух, не знаючи, як боротися з NULL).

Незмінні ФК для необов'язкових відносин багато-до-одного абсолютно добре.

Я чув, як він стверджував, що Nullable стовпчики взагалі є першою ступеня нормалізації. Але на практиці це дуже практично.

Так, це щось не так. Це не іноземний ключ, якщо його нульовий. Його дизайн бази даних за кодом. Можливо, ви зробите нульове посилання на непризначене. або "Неприсвоєно", якщо ви використовуєте знак символів. Зберігайте цілісність своїх даних на 100%.