Як зберігати статуси записів (наприклад, очікування, завершення, чернетка, скасування ...)

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

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

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

1. У таблиці "Пост" є текстове поле, що включає текст статусу.
2. У таблиці "Пост" є поле статусу, яке містить ідентифікатор запису в таблиці PostStatus

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

Чи може хтось пояснити переваги / недоліки кожного?

Ура!

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

Збереження статусу в якості індексу в іншій таблиці - зайве ускладнення. Зберігайте стан безпосередньо в таблиці з легким читанням. У коді програми використовуйте константи або тип перерахунку. Це призведе до більш простого коду програми та полегшення налагодження рівня даних.

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

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

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

Я бачив у багатьох програмах або числовий код (1 = новий, 2 = чернетка, 3 = під час перевірки, 4 = повний, 99 = скасований), або короткий буквено-цифровий код ("НОВО", "DRA", "INV "," COM "," CAN "). Пізніше робить код (у програмі чи в базі даних) більш зрозумілим для людини, що, як правило, є хорошою справою. З іншого боку, числові коди полегшують порівняння, наприклад, "більше" або "менше"

select * from myrecords where status < Status.Complete;

Три правила реляційних баз даних:

1. Нормалізувати
2. Нормалізувати
3. Нормалізувати

Отже, ваше запитання відповідає самому собі. Зберігайте статус у власній таблиці та використовуйте GUID / UUID, як свій ідентифікатор . Індексований GUIDS дуже швидкий і виправляє проблеми, притаманні приросту чисел. З ідентифікатором ви можете робити цікаві речі, як-от запитати БД для всіх завершених постів, використовуючи ідентифікатор, і оскільки ви працюєте в реляційній парадигмі db, це дуже швидко. Якщо у вас є просто поле, БД повинен перебирати цикл на кожному рядку і робити порівняння тексту, можливо, із зміною, і це дуже повільно.

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

Наприклад, ви можете додати рівні статусу як додаткову інформацію, яка б дозволила порівняти згадування ammoQ. Але вони не залежать від ключа позиціонування, що дозволяє переставляти рівень статусу без шкоди для цілісності БД. Ви також можете вставити додаткові рівні, що є досить хитрощами, якщо у вас є рівень, пов’язаний з ключем для автоматичного підвищення.

Так, вам слід скористатися варіантом 2, маючи таблицю PostStatus.

Крім усіх переваг, згаданих в інших відповідях.

Маючи на увазі, що статуси потрібно додати або видалити, ви можете мати стовпчик "увімкнено" у таблиці PostStatus, тому якщо статус видалено, позначте стовпець "увімкнено" як "N", таким чином ви зможете додавати або видаляти статуси, а також наявні записи залишатимуться без проблем.

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

Вам знадобиться додаткове приєднання до об’єкта statusChange, але ви виграєте можливість додавання додаткової інформації, наприклад, про актора, який виконує зміну, можливих коментарів щодо того, чому зміни відбулися, та дати, коли statusChange виконується і, можливо, навіть коли воно стає ефективним.

Використання тексту для отримання статусу в таблиці записів, ймовірно, не буде гарною ідеєю, оскільки це може змінитися, і було б важко виконати будь-які перевірки цілісності даних щодо вставки / оновлення. Якщо ви використовуєте СУБД з типом даних enum, ви можете використовувати це замість цього (продуктивність, ймовірно, не буде порушена ... залежно).

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

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

Залежить від мети проектування бази даних.

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

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

Правильне рішення - використовувати або магазин / джерело події з CQRS, або блокчейн. Проблема з захопленням подій в RDB полягає в тому, що RDB зберігає в часі знімок однієї події, а такі речі, як "Статуси / штати", - це послідовність мутацій, що розвиваються з часом