Як я можу представити перелічений тип у реляційній базі даних?

12

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

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

Примітка: явні перелічені типи не підтримуються базою даних, яку ми використовуємо. А програмне забезпечення, яке ми розробляємо, яке буде взаємодіяти з цією базою даних, написане на C ++.

database-design relational-database

— c.hughes
джерело

Чи вражає він когось іншого, поки прострочено, щоб просто зробити його перевіреним визначенням типу в таблиці створення? Щось на зразок: CREATE TABLE hit (ip varchar (40), ip_class ENUM (0, "IPv4", 1, "IPv6")); Це повинно дозволяти вам перевіряти = <і> або порядковим, або рядковим (що відображається на порядковій).

— dlamblin

26

Перелічені типи повинні бути окремою таблицею у вашій базі даних, яка має ідентифікаційний номер та ім'я рядка та будь-які інші стовпці, які можуть вам бути корисними. Тоді кожен тип існує як рядок у цій таблиці. Потім у вашій таблиці ви записуєте транзакції, поле "trans_Type" має бути зовнішнім ключем до ключа цієї довідкової таблиці. Це стандартна практика нормалізації бази даних.

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

— Рятал
джерело

1

Так, і якщо ви вирішите, що хочете змінити "O" на "Відкрити", вам потрібно змінити лише один рядок.

— Даніель Каплан

+1. проста таблиця int / string - найкращий спосіб представити переписки у реляційному db.

— mike30

Можливо, такі відвідувачі , які шукають рішення Java знайти це корисним

— Jauhien

2

Це. Для додаткового кредиту - якщо команда розробників визначила цілі числа в перерахунку Java / C # або щось подібне, ви можете написати тест, який перевіряє, чи визначилося визначення enum коду від таблиці пошуку. Завжди існує небезпека, що додавання елемента в послідовність може вивести з ладу синхронізацію, і ви не усвідомлюєте, поки запис живих даних не стане невірним.

— Джулія Хейвард

4

Поширена практика - створити trans_typesтаблицю, а потім посилати її на свою основну таблицю з іноземним ключем trans_type_id. Це гарантує, що ваші записи будуть посилатися лише на дійсні перелічені типи.

Приклад:

транс_тип
----------
  ід
  назва

транзакцій
------------
  ід
  trans_date
  деталі
  trans_type_id (від FK до trans_type.id)

Приклад даних:

транс_тип

Ідентифікатор | ІМ’Я
----------
1 | ПОДІБИТИ
2 | ОТМИНАЙТЕ


транзакцій

Ідентифікатор | trans_date | trans_type_id
---------------------------------
1 | 2012-12-31 | 1
2 | 2013-01-09 | 2

— FrustratedWithFormsDesigner
джерело

3

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

Це має додаткову перевагу в оновленні рядкового значення в одному місці замість того, щоб виконувати якусь процедуру оновлення. Замість 1 = 'Червоний' він міг би дорівнювати 'Дійсно Червоний'

Це не ідеально для звітності про ефективність порівняно з просто необхідністю однієї таблиці зі значеннями рядків (денормалізовані). Індекс на цьому полі зробить ефективність досить хорошою.

Більшість RDBMS дозволять отримати достатню кількість кінських сил. Хоча ваше уявлення про можливість "читати" таблицю у простому вигляді даних, приєднання до таблиці не є великою справою. Просто ввійдіть у звичку використовувати вид або якийсь подібний предмет.

— JeffO
джерело

2

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

Однак я, безумовно, виступаю за те, щоб не повторювати сказане, тому я просто посилаюся на прийняту відповідь на (більш-менш) те саме питання щодо переповнення стека: /programming//a/229919 / 114626

— Еял Рот
джерело

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

— Харке