1 Тема від kolbok

  • kolbok
  • Новий користувач
  • Поза форумом
  • Дата реєстрації: 12.08.2022
  • Повідомлень: 3
    • Репутація: 0

Тема: Одна таблиця істрорії чи декілька

Доброго дня, потрібна порада як краще вчинити

У мене є 10 entity і у кожної є, наприклад, по 10 станів, і перехід між кожним станом, я хочу зберігати історію переходів, при кожному переході зберігати трьох користувачів ім'я переходу і коментар, з таблиці/таблиць буде лише вибірка.

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

Усього п'ять користувачів кожен має посаду, тобто. в першій сутності в переходах братимуть участь master, controller, apparatchik а в другій сутності master, controller, zam наприклад

Думав створити одну таблицю з історією там будуть поля (master, controller, apparatchik, zam, transition_name, comment)
і складати туди всю історію, або створити під кожну сутність свою таблицю з історією, або 3 таблиці, 3 модулі - у кожному по 3-3-4 сутності

і як краще зберігати поля користувачів у таблиці, може все id користувачів покласти в одне поле json або для кожного користувача нехай буде посилання

на місяць кількість переходів з усіх створених сутностей буде не більше 500-600 нехай буде 1000 із запасом

раз на місяць або в два буде братися звіт куди я вивантажуватиму імена цих користувачів з конкретних переходів, ось

2 Відповідь від quwy

  • quwy
  • quwy
  • Новий користувач
  • Поза форумом
  • Дата реєстрації: 20.06.2022
  • Повідомлень: 37
    • Репутація: 30

Re: Одна таблиця істрорії чи декілька

Залежить від багатьох факторів.

Нормальна форма вимагає, щоб у таблиці акцій не було жодних інших даних, крім transition_name, та, ймовірно, comment. Користувачі мають бути складені в окрему таблицю, що посилається на унікальний ключ таблиці акцій. При цьому користувачі мають бути лише по id.

Але. Нормальна не є єдиним критеріем правильності. Наприклад, чи може по бізнес-логіці користувач бути видалений з умовної таблиці users? Якщо так, то при такому видаленні ми руйнуємо історичну інформацію, бо з id видаленого користувача (чи навіть NULL) вже нічого не витягнеш. Хто видалив документ рік тому? Юзер 335 або взагалі NULL! У цій ситуації треба зберігати максимум текстової інформації з таблиці користувачів, а не просте посилання.

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

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

3 Відповідь від frz

  • frz
  • frz
  • Data / DB Engineer
  • Поза форумом
  • Звідки: PL
  • Дата реєстрації: 28.12.2019
  • Повідомлень: 7 282

Re: Одна таблиця істрорії чи декілька

Я за нормалізовану єдину таблицю, якщо не йдеться про продукт типу Snowflake чи Redshift із потужним кластером на бекенді. Бо воно працює ок на етапі dev/staging, а при розростанні на проді починає захлинатися власне від поганої архітектури, де сам собі винен бо "раніше було все ок".

frz вебсайт

4 Відповідь від kolbok

  • kolbok
  • Новий користувач
  • Поза форумом
  • Дата реєстрації: 12.08.2022
  • Повідомлень: 3
    • Репутація: 0

Re: Одна таблиця істрорії чи декілька

Користувачі видалятися не будут, тож посилання я гадаю буде норм, гадав зробити json и туді класти id і full name користувача і у звіті браті лише full name щоб не створюваті зайві запити до бази, но це таке

така тема що звіт не для усіх entity, один звіт для 3, другій для 4-х, якось так, якщо одна то при кожному звіті буде вікорустовуватіся 1-на велка табліця

ці entity це типу ДЕТАЛІ, ДВИГУН інші частики яки збираются з инших великих частин у якіх є наприклад 10 статусів и 9 перетинів, кожни перетин контролюють або КОНТРОЛЕР або МАЙСТЕР И КОНТРОЛЕР або інші, максимум 3 і завжді є контролер, і якщо адміністратору потрибно буде вивесті спливаючий лист исторії кожною детали, деталі будуть з кожним разом збільшуватісь, різні вироби, тож виходить що кожний виріб буде смикати таклицю де є багато записів інших виробів

якщо розбіти на різні табліці, то вибірка у ЛИСТ буде бистрішою я гадаю для адміна, для звіту доведеться смикати 3 таблиці

може не створювати таблицю а у кожному виробі створити массив и туді класти user_id, user_name, date_time, transition_name, full name для звіту, id для ідентифікації, щод підсказує що це не дуже

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

якось дуже важко визначиться