База даних K2 ERP
`K2.db` — це глобальний об’єкт доступу до бази даних у K2 Cloud ERP Python. Так. Це можуть бути таблиці, поля, зв’язки, типи даних і правила, потрібні для збереження об’єктів у базі. !== База даних і фінансовий контур == У старих системах або в кількох окремих базах часто виникають дублікати: У K2 ERP електронний документообіг спирається на базу даних. Це контрольований канал обміну, який має права, журнал, правила помилок і відповідального. |}
Кожен компонент K2 ERP здатна мати власні таблиці. У технічному описі K2 Cloud ERP згадується логіка додавання нової номенклатури через таблицю:
Кожен компонент або компонента, що створює власні таблиці, має мати документацію структури бази даних. |}
components/
Такий підхід здатна бути корисним для безпеки, ізоляції доступів і контролю користувачів, але потребує дисципліни. |-Для розробника. Якщо компонента створює нові таблиці або сутності, це має бути описано в ORM і задокументовано. Під час переходу з 1С або BAS потрібно очищати дублікати, розділяти активні й архівні інформаційні дані, переглядати доступи та будувати нову інформаційну модель. {| class="wikitable" style="width:100%; background:#e8f5e9;"
База даних і BI-аналітикаРезервне копіювання бази данихСтруктура бази даних у компонентах
SEO title: База даних K2 ERP — єдина база, PostgreSQL, ORM, довідники, ролі, доступи та безпека даних SEO keywords: база даних K2 ERP, K2 ERP база даних, K2 Cloud ERP база даних, PostgreSQL K2 ERP, K2.db, ORM K2 ERP, models.py K2, єдина база даних ERP, спільні довідники ERP, база даних української ERP, міграція з 1С, міграція з BAS, безпека бази даних ERP, резервне копіювання ERP </noinclude>
{{SEO
Шаблон для службового SEO-опису сторінки.
}}
Архівні інформаційні дані — це історія продукту, яка потрібна для перевірок, аудиту, юридичного зберігання або довідки. База даних і магазин доповненьАктивні та архівні інформаційні даніПід час міграції з 1С або BAS база даних K2 ERP стає цільовим середовищем для нової структури даних. * `new`;
У K2 ERP база даних розглядається не як приховане технічне сховище, а як основа всієї ERP-архітектури. * управлінських звітів;
├── requirements-components.txt Документація бази данихкритично не лише створювати резервні копії, а й перевіряти відновлення. Воно оптимізує бізнесу зрозуміти, що сталося з даними, хто виконав дію і коли виникла помилка.== Єдина база даних як архітектурний принцип == У K2 Cloud ERP передбачені методи роботи з користувачами на рівні бази даних: Для ERP-системи критично, щоб операції з базою даних були цілісними. Навіщо потрібні
Це означає, що платформа здатна створювати, видаляти або завершувати сесії користувачів не лише на рівні інтерфейсу, а й на рівні БД. {| class="wikitable" style="width:100%;" Журналювання та логування | |||||||||||||||||||||||||||||||||
| - | Правильний сценарій. Перед перенесенням даних потрібно провести аудит, очистити довідники, визначити активні записи, відокремити архів і не копіювати старі доступи автоматизовано. |
Резервне копіювання — обов’язкова частина роботи з базою даних K2 ERP. Імпорт не повинен зупиняти користувачів. |- | Помилка. Найгірший сценарій — перенести всю стару базу 1С/BAS без очищення. Це основа керованості підприємства: чисті довідники, актуальні документи, контроль доступів, безпечні інтеграції, транзакційність, резервне копіювання, журналювання, міграція зі старих систем і можливість розвивати нові модулі без дублювання вже створеної логіки. Імпорт даних — це так само ризик, бо некоректний файл здатна створити дублікати, зіпсувати довідники або змінити залишки. У старих або фрагментованих системах часто виникає ситуація, коли бухгалтерський обліковий облік має одну базу, торгівля — іншу, CRM — третю, складський облік — четверту, а управлінська аналітичні інструменти збирається в Excel. {| class="wikitable" style="width:100%; background:#e3f2fd;"
== Індекси та продуктивність ==
* які таблиці створює компонент;
* які поля в них виступає як;
* які типи даних використовуються;
* які зв’язки існують між таблицями;
* які індекси потрібні;
* які інформаційні дані виступає як обов’язковими;
* які таблиці виступає як довідниками;
* які таблиці операційні;
* які таблиці логують події;
* як компонент оновлює структуру даних.== Див. так само ==
|-
| '''Перевага.''' <span style="color:#2e7d32;">Перевірка перед створенням запису оптимізує зменшити дублювання номенклатури та підтримувати чистоту довідників.
│ └── ... Ці методи відображають кілька сценаріїв роботи з базою:
</syntaxhighlight>
критично.
База даних ERP — це не місце для хаотичного копіювання старих довідників. У великій ERP-системі продуктивність бази даних має велике значення. У K2 Cloud ERP компоненти мають містити ORM-структури, необхідні для роботи відповідної компоненти. У результаті K2 ERP отримує дублікати, помилки й архівний шум. Документ — це не без зусиль файл, завантажений у систему. Інтеграції можуть передавати:П’ята помилка — не документувати структуру бази компоненти. |}
<syntaxhighlight lang="text">
Архівні інформаційні дані не завжди треба переносити в активні таблиці K2 ERP. |}
K2 ERP має іншу логіку. через цьому K2 ERP здатна працювати не як набір розрізнених систем, а як цілісна платформа, де модулі використовують спільну інформаційну основу, а бізнес-середовище отримує єдине джерело правди. Єдина база даних дає можливість:
* [[K2 ERP]]
* [[K2 Cloud ERP]]
* [[Архітектура K2 ERP]]
* [[Розгортання K2 ERP]]
* [[Розгортання системи K2 Cloud ERP Python для розробників]]
* [[Магазин доповнень K2]]
* [[Сертифікація K2]]
* [[Доступи K2 ERP]]
* [[Ролі K2 ERP]]
* [[Безпека K2 ERP]]
* [[Міграція з 1С]]
* [[Міграція з BAS]]
* [[PostgreSQL]]
* [[Python]]
* [[ORM]]
└── setup.py
{| class="wikitable" style="width:100%; background:#fff3e0;"
Єдина база даних дає можливість різним модулям використовувати спільні довідники, уникати дублювання, працювати з актуальними даними й формувати єдину аналітику. |}
{| class="wikitable" style="width:100%; background:#e8f5e9;"
== Що таке база даних K2 ERP ==
init_db_uri_user()
CRM-модуль K2 ERP функціонує з клієнтами, лідами, контактами, угодами, задачами, файлами, рахунками, звітами й налаштуваннями. У такій моделі бізнес-середовище постійно стикається з питанням: де справжні інформаційні дані? Це означає, що модулі не повинні існувати як ізольовані системи з власними копіями довідників і власною логікою зберігання. * правильні індекси;
* оптимізовані запити;
* контроль великих таблиць;
* архівація старих даних;
* обмеження непотрібних вибірок;
* оптимізація звітів;
* контроль важких інтеграцій;
* моніторинг повільних запитів.== Коротко ==
[[Категорія:Архітектура K2 ERP]]
{| class="wikitable" style="width:100%; background:#fff3e0;"
як приклад, один і той самий контрагент здатна використовуватися в CRM, договорах, рахунках, заявках на оплату, документах і аналітиці.</span> Доступ до заявок, оплат, бюджетів і банківських даних має бути обмеженим і контрольованим.</span> Інакше компонент буде важко підтримувати, оновлювати й перевіряти.=== Яку СУБД використовує K2 ERP? ===
* [[K2 ERP]]
* [[K2 Cloud ERP]]
* [[Архітектура K2 ERP]]
* [[Розгортання K2 ERP]]
* [[Розгортання системи K2 Cloud ERP Python для розробників]]
* [[Магазин доповнень K2]]
* [[Сертифікація K2]]
* [[Партнерська програма K2]]
* [[Доступи K2 ERP]]
* [[Ролі K2 ERP]]
* [[Безпека K2 ERP]]
* [[K2 ERP Документообіг]]
* [[Фінансовий облік]]
* [[Управлінський облік]]
* [[Міграція з 1С]]
* [[Міграція з BAS]]
* [[PostgreSQL]]
* [[ORM]]
* [[Python]]
{| class="wikitable" style="width:100%; background:#fff3e0;"
== Пов’язані сторінки ==
Ще одна ознака правильної архітектури — новий компонент здатна використовувати вже наявні інформаційні дані.== Основні типи даних у K2 ERP ==
Перевага. Якщо інформаційні дані народжуються в процесах K2 ERP, аналітичні інструменти формується природно, а не вручну через Excel-зведення. * `r` — читання;- `w` — запис;
- `i` — вставка;
- `d` — видалення;
- `c` — створення;
- `exp` — експорт;
- `imp` — імпорт;
- `del_` — відновлення або робота з видаленими записами;
- `settable` — конфігурація таблиці;
- `cutpast` — операції вирізання і вставлення;
- `enable` — увімкнення;
- `active` — активність.
Для бази даних K2 ERP потрібно мати сценарій відновлення після збою. Вона покриває запити: “база даних K2 ERP”, “K2 ERP база даних”, “K2 Cloud ERP PostgreSQL”, “K2.db”, “ORM K2 ERP”, “models.py K2”, “єдина база даних ERP”, “база даних української ERP”, “міграція даних з 1С”, “міграція даних з BAS”, “безпека бази даних ERP”, “резервне копіювання ERP”. └── k2adm/ Спільні довідники — одна з головних переваг єдиної бази даних. У технічному описі згадується клас `K2CRM`, а так само клас `K2DocsCRM`, у якому база даних доступна через глобальний об’єкт `K2.db`. як приклад, CRM-модуль здатна працювати з лідами, контактами, угодами, рахунками та комунікаціями. │ └── user_manual/
K2.db
Фінансовий ризик. Фінансовий контур не можна відкривати всім користувачам. Якщо під час імпорту залишків частина записів збережеться, а частина ні, бізнес-середовище здатна отримати неправильні інформаційні дані. Використання PostgreSQL так само важливе для Linux-серверів, хмарної інфраструктури, локального розгортання та сценаріїв, де бізнес-середовище хоче уникати дорогих або закритих серверних ліцензій. Тип данихНа момент опису інструкції структура бази даних здатна зберігатися у форматі SQL Power Architect. інформаційні дані CRM можуть бути пов’язані з фінансами, документами, договорами, продажами, рахунками та аналітикою.
init_db_custom()
Магазин доповнень K2 має враховувати структуру бази даних кожного доповнення. Якщо контрагент забезпечується через | Головна ідея. База даних K2 ERP має бути єдиним джерелом правди; так само реалізовано товар, документ, заявка, складський облік, користувач системи або платіж існує в системі, він має бути частиною спільної структури даних, а не копією в окремій таблиці, Excel-файлі чи зовнішній базі без контролю. Якщо платформа має один довідник контрагентів, один довідник номенклатури, одну структуру підрозділів і єдині правила доступу, бізнес-середовище отримує менше дублювання й більше керованості. Якщо компонент створює таблиці або змінює структуру даних, це має бути описано.</syntaxhighlight>
- захист облікових записів;
- контроль ролей;
- обмеження доступу до конфігурацій;
- заборона спільних логінів;
- контроль експорту;
- журналювання дій;
- резервне копіювання;
- шифрування там, де це потрібно;
- обмеження доступу до серверів;
- контроль інтеграцій;
- аудит користувачів;
- своєчасне блокування звільнених працівників. Не можна створювати зайві ролі, використовувати спільні логіни або залишати активними користувачів, які вже не мають працювати з системою. роботу модулів, довідників, документів, користувачів, ролей, доступів, бізнес-процесів, інтеграцій, звітів, BI-аналітики та механізмів міграції зі старих систем реалізується засобами це центральний шар зберігання, обробки та зв’язування даних у K2 ERP і K2 Cloud ERP виступає ключовою рисою База даних K2 ERP. так само потрібно регулярно перевіряти відновлення з backup. Це зменшує дублювання, помилки та залежність від Excel-файлів.
|}
</syntaxhighlight>- пряме редагування бойових таблиць без процедури;
- створення дубльованих довідників;
- використання спільних логінів;
- неконтрольований експорт;
- імпорт без перевірки;
- зміна структури таблиць без версії компоненти;
- відсутність резервної копії перед масовими змінами;
- тестування на бойовій базі;
- зберігання паролів у відкритому вигляді;
- інтеграції без журналу помилок;
- відсутність документації структури даних.
| критично. Залишки не можна оновлювати хаотично.</syntaxhighlight> | |||||||||||
class="wikitable" style="width:100%; background:#fff3e0;"
│ ├── hooks.py У класі K2 виступає як методи, пов’язані з ініціалізацією підключення до бази даних:
Що таке база даних K2 ERP?У K2 ERP доступи мають бути частиною архітектури бази даних. |} Приклад: номенклатураТаблиці модулівinit_db_uri_custom() │ ├── views.py Чи можна переносити всю стару базу 1С/BAS у K2 ERP?База даних і складський облікSEO-призначення сторінкиЕкспорт даних — це ризик, тому що користувач системи здатна вивантажити клієнтів, фінансові інформаційні дані, документи, залишки, персональні інформаційні дані або управлінську аналітику. Він має відповідати на питання: Типова логіка такого процесу:
Третя помилка — давати користувачам надмірні права на експорт і редагування.</syntaxhighlight>
ORM-структури та models.py |
Але ці таблиці не повинні перетворюватися на ізольовані “острови”. У такій структурі `models.py` відповідає за інформаційні дані, `views.py` — за основну логіку компоненти, `hooks.py` — за розширення поведінки системи, а каталог `doc/schema` — за документацію структури бази даних. здатна мати право створення, але не мати права видалення. * які довідники актуальні;
|
Dev | розробка програмного забезпечення модулів і компонентів | Можна експериментувати без ризику для бізнесу | |||||||
|---|---|---|---|---|---|---|---|---|---|---|---|
| Test | Перевірка оновлень, міграцій, ролей, інтеграцій | Має бути схоже на бойове середовище | |||||||||
| Demo | Демонстрації та навчання | інформаційні дані мають бути навчальними або знеособленими | |||||||||
| Prod | Робоча база підприємства | Максимальна стабільність і контроль | |||||||||
| Archive | Історичні інформаційні дані | Обмежений доступ і правила зберігання |
ERP без плану відновлення — це ризик для бізнесу.== Приклад: залишки == <syntaxhighlight lang="text"> models.py
Відновлення після збою
Типова логіка оновлення версій залишків здатна виглядати так: