Синхронізація збереження перерахунку та таблиці

11

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

  Статус
  Ідентифікаційний опис
  --------------
   0 необроблений
   1 Очікує на розгляд
   2 Оброблено
   3 Помилка

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

Я міг би жорстко кодувати статус Id в перерахунку і сподіваюся, що ніхто ніколи не змінить базу даних. Або я міг би заздалегідь отримати значення на основі опису (таким чином, жорстке кодування, що замість цього).

Який був би правильний підхід для синхронізації цих двох, перерахунків та таблиць?

database enum

— MPelletier
джерело

Чому ви зберігаєте речі синхронно, а не синхронно? Синхронізація (скажіть це) дивна!

— MrFox

1

@suslik Вони обидва вимовляються однаково. Синхронізація та синхронізація .

— MPelletier

1

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

— Пітер Сміт

Це залежить від контексту. У цьому випадку, будучи значеннями робочого процесу або статусу завдання, я прагну підтримувати їх більш динамічними над статичними, оскільки процеси часто мають тенденцію до зміни; і, як правило, змінюються поза діапазоном для графіків випуску програмного забезпечення. З іншого боку, якщо його стабільний сервіс, який навряд чи матиме нові стани або буде видалено існуючі стани, я, можливо, буду більше змушений жорстко кодувати enum / денормалізувати їх (залежно від того, як записи використовуються пізніше).

— JustinC

@PeterSmith База даних не може застосувати обмеження, якщо вони знаходяться лише у вашій перерахунку Java, а не в таблиці. Ви збираєтесь обмежувати значення у вашій базі даних, чи не так?

— Девід Конрад

5

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

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

— Метью
джерело

Йдеться не стільки про нові статуси (які, безумовно, вимагають зміни як бази даних, так і програми), а значення Id.

— MPelletier

2

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

— Метью

Ну так, це ідея. Але якщо я встановити посвідчення особи на одне місце іншим, я працюю з припущенням, що вони обидва праві. Це вільне посилання, ні?

— MPelletier

3

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

— Матвій

8

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

— FrustratedWithFormsDesigner
джерело

2

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

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

Зазвичай у мене є невеликий фрагмент коду, який підключиться до БД і переконається, що статуси, перелічені в певній таблиці, мають однакові значення id / name, які я жорстко кодував у пам'яті. Якщо вони не збігаються, я припиняю виконання програмного забезпечення.

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

— Олексій
джерело

2

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

По-перше, і найкраще, коли це можливо, усунути прямі посилання на ці значення. Завжди запитайте: "чому мені потрібно безпосередньо використовувати значення enum?" У багатьох випадках це знак того, що в коді занадто багато жорстких кодованих припущень або намагаються зробити занадто багато маніпуляцій над даними. Перевірте, чи не можете ви налагодити кращі стосунки в базі даних або більш гнучкий код, щоб обробити те, чим маніпулюють.

Коли це не працює, я переходжу до плану B: генерація коду. Оскільки таблиці змінюються нечасто і ми регулярно публікуємо нові збірки, генератор коду може читати таблиці enum та писати код enum. Ця динамічно створена бібліотека потім використовується у проекті. Якщо БД зміниться, наступна збірка не буде компілюватися, що набагато краще, ніж отримання таємничих помилок виконання.

— CodexArcanum
джерело

Як би ви усунули згадки про перерахунок? Наприклад, ви сортуєте або шукаєте за статусом у цьому випадку. Маючи в БД якесь магічне значення, мені теж не добре. Саме для цього призначені таблиці пошуку.

— nportelli

У минулому я робив навпаки. Щоразу, коли в Enum відбувається зміна коду, під час завантаження програми він синхронізує ці значення з Database. Тут код - джерело істини. База даних - це її представлення. Зазвичай я ігнорую значення в БД, які код не може зрозуміти, але таким чином я отримую механізм автоматичного очищення БД, якщо потрібно.

— Anshul