ORM

Це дає можливість розділяти інформаційні дані між організаціями. У контексті K2 ERP ORM здатна бути частиною серверної логіки, яка функціонує з довідниками, документами, користувачами, ролями, замовленнями, платежами, залишками, договорами, номенклатурою та аналітичними даними. {| class="wikitable" style="width:100%;"

користувач системи видаляє товар, який уже був у продажах. ! email

ORM добре підходить для:

Фізичне видалення небезпечне, бо старі документи втратять посилання. # Закрити борг постачальника. Об’єкт у коді

• customers;
• orders;
• invoices;
• products;
• payments;
• users;
• roles;
• warehouses;
• contracts;
• documents.

Спочатку ORM отримує клієнта. class Product:

Зв’язок один до багатьох

email

• права доступу;
• фільтрацію за організацією;
• фільтрацію за користувачем;
• API-доступи;
• масове оновлення версій;
• експорт даних;
• аудит змін;
• доступ до персональних даних;
• доступ до зарплати;
• доступ до банківських реквізитів. як приклад:

ORM і K2 ERP

'''ORM''' — це технологія, яка зв’язує об’єктну модель програми з реляційною базою даних. # Створити Customer або Supplier. Сутність
! customer

Для цього в базі часто створюється проміжна таблиця:

ORM здатна зменшити ризик SQL-ін’єкцій, якщо правильно використовувати параметризовані запити. # ORM формує SQL-запит. Якщо неправильно будувати моделі, зв’язки й запити, ORM здатна створювати повільні запити, дублювати інформаційні дані, перевантажувати сервер і приховувати помилки архітектури. Поля
== ORM і міграції бази даних ==

У коді це здатна виглядати так:

 id

CRUD — це базові операції з даними:

Потрібно перенести список контрагентів у нову ERP.=== Чи підходить ORM для ERP? ===

=== Які ризики ORM? ===

== Зв’язок багато до багатьох ==

# Створити об’єкт Order. Це функціонує, але в великій ERP-системі таких запитів можуть бути тисячі. Якщо помилка сталася на етапі закриття боргу, платіж не повинен залишитися “наполовину проведеним”.=== Чи замінює ORM SQL? ===

Але безпека залежить не тільки від ORM. Таблиця в базі

як приклад:
виступає як таблиця клієнтів у базі даних. Товар
orders = customer.orders

'''Модель''' — це клас або структура, яка описує інформаційні дані певного бізнес-об’єкта. Але ORM впливає на якість даних:
WHERE id = 15;
У базі це будуть колонки таблиці ''orders''. користувач системи має доступ тільки до складу №1. як приклад, модель Product здатна відповідати таблиці products. Потім повертає відповідь у JSON. Поле

== ORM і зовнішній ID ==

! Модель — це клас або структура в коді, яка відповідає таблиці бази даних. ! ORM пов’язує клас із таблицею. Поле

stock.save()

== ORM в ERP ==

# Створити платіж. Поле

== Приклад soft delete ==

* створювати записи;
* читати записи;
* оновлювати записи;
* видаляти записи;
* описувати зв’язки між таблицями;
* працювати з транзакціями;
* зменшувати кількість ручного SQL;
* робити код зрозумілішим;
* повторно використовувати моделі;
* будувати API;
* підтримувати бізнес-логіку;
* контролювати цілісність даних;
* пришвидшувати розробку ERP або CRM. * users;
* roles;
* user_roles. active

як приклад, одразу отримати замовлення разом із клієнтами й рядками:

== ORM в CRM ==

* довідниками;
* документами;
* користувачами;
* ролями;
* договорами;
* платежами;
* складськими залишками;
* замовленнями;
* виробничими операціями;
* сервісними заявками;
* API;
* аудитом;
* інтеграціями;
* Power BI-вивантаженнями. GET /api/orders/10425

class Customer:

* створення записів;
* оновлення версій;
* видалення;
* зв’язки;
* транзакції;
* валідацію;
* обмеження доступу;
* поведінку при помилках;
* міграції;
* продуктивність запитів. # Зменшити залишок коштів. sku

ORM часто дає можливість описувати правила перевірки даних. # Перевірити залишки. як приклад, клієнт ERP, товар або замовлення стають моделями програми. WHERE id = 15;
Інакше база здатна переглядати тисячі або мільйони рядків. # База даних виконує запит. {| class="wikitable" style="width:100%;"

Це інтуїтивно, але здатна створити проблему продуктивності. ORM дає можливість програмі працювати з даними бази не напряму через SQL-запити, а через об’єкти, класи, моделі та сутності в коді. name

• приховані SQL-запити;
• ризик повільної роботи;
• N+1 проблема;
• складність оптимізації;
• надмірне завантаження даних;
• не завжди підходить для складної аналітики;
• залежність від фреймворку;
• ризик неправильної моделі;
• складність при великих обсягах даних;
• ілюзія, що SQL знати не потрібно. Краще винести частину логіки в сервіси. | 180 грн

| 18 000 грн |- | Зарядний адаптер | 50 шт. Що означає У програмі розробник функціонує з об’єктами: Типові зв’язки:

Популярні ORM-підходи

|- | Create | Створити запис | Створити нового клієнта |- | Read | Прочитати запис | Відкрити замовлення |- | Update | Оновити запис | Змінити статус рахунку |- | Delete | Видалити запис | Видалити чернетку документа |}

Така модель стає занадто великою й складною. Практичний приклад. Замість SQL-запиту SELECT * FROM orders WHERE customer_id = 15 ORM дає можливість написати щось схоже на customer.orders або Order.findByCustomer(customer). ! Сторінка “продажі та реалізація за рік” відкриває всі документи реалізації, всі рядки, всіх клієнтів, всю номенклатуру й усі платежі.

SELECT *

Чи можна використовувати ORM для міграції даних?

ORM здатна виконати: Приклади:

класу Order, а рядок у таблиці — конкретному об’єкту в коді виступає ключовою рисою Простіше кажучи, ORM перетворює таблиці бази даних на об’єкти програми.

StockBalance.filter(warehouse=user.allowed_warehouse)

Приклади:

* id;
* номером документа;
* датою;
* клієнтом;
* договором;
* статусом;
* артикулом;
* складом;
* організацією;
* зовнішнім ID;
* email;
* телефоном. Типові помилки:
)
то поле ''external_order_id'' має бути індексованим. Модель ''Order'' містить:

== Приклад CRUD для клієнта ==

'''Шапка замовлення:'''

{| class="wikitable" style="width:100%;"
== ORM і Power BI ==
як приклад, код:

customerRepository.findById(15)

 contract=contract
! Сервер через ORM шукає замовлення:
|-
| 1
| API отримує JSON із сайту
|-
| 2
| ORM шукає клієнта по телефону
|-
| 3
| ORM шукає товари по артикулу
|-
| 4
| ORM створює замовлення
|-
| 5
| ORM створює рядки замовлення
|-
| 6
| платформа повертає номер замовлення
|}

ORM не скасовує потребу в індексах бази даних. |}

ORM здатна допомагати працювати з:
== конкурентні переваги ORM ==
Один клієнт ERP здатна мати багато замовлень. ! Зв’язок

У бізнес-системах критично знати, хто змінив інформаційні дані. # Зберегти замовлення. Сутність
як приклад:
'''Soft delete''' — це м’яке видалення. Потім потрібно вручну перетворити результат у структуру програми. ! ORM здатна бути не найкращим варіантом для:

! # Записати рух у регістр. Замовлення клієнта здатна містити шапку й рядки. # Отримати 501 запит до бази. |-
| Що таке ORM? # Для кожного клієнта окремо запитати замовлення. Поле

== ORM і права доступу ==

Якщо ERP часто шукає замовлення за зовнішнім ID сайту:

* прочитати клієнтів;
* створити товари;
* перенести довідники;
* створити користувачів;
* перенести конфігурація. # Перевірити ЄДРПОУ. У великих ERP-проєктах ORM зазвичай не виступає як єдиним способом роботи з даними. phone

Але кеш потрібно правильно оновлювати, інакше користувачі бачитимуть старі інформаційні дані. customer.email = "new@example.com"
|-
| клієнт ERP
| id, name, phone, email, source_channel
|}

У HRM — працівник.

критично. ORM не скасовує SQL і не робить базу даних “простою автоматизовано”. name

ORM у фінансах

Потрібно показати список клієнтів і суму їхніх замовлень.== Приклад міграції ==

ORM потрібен, щоб швидше й зручніше створювати, читати, оновлювати й видаляти інформаційні дані без ручного написання кожного SQL-запиту. * клієнт ERP;

• замовлення;
• рахунок;
• товар;
• платіж;
• користувач системи;
• роль;
• складський облік;
• договір;
• документ.

! |- | Що виступає як основою ORM? Без ORM програміст здатна писати SQL вручну: У CRM ORM здатна працювати з такими сутностями: <pre> {| class="wikitable" style="width:100%;" компанія-користувач хоче додати в модель клієнта поле “канал залучення”. Приклади: Приклад: * зрозумілий код; * швидшу розробку; * менше дублювання SQL; * стабільні моделі; * кращу підтримку API; * зручні міграції; * контроль транзакцій; * кращу тестованість; * простіше масштабування команди; * чистішу бізнес-логіку. Значення __TOC__ == Пов’язані сторінки == == ORM і інтеграції == Після міграції можна аналізувати, звідки прийшов клієнт ERP: == ORM у міграції даних == {| class="wikitable" style="width:100%;" |- | 1 | ТОВ “клієнт ERP Плюс” | info@example.com | +380XXXXXXXXX |- | 2 | ФОП Іваненко | ivanenko@example.com | +380XXXXXXXXX |} Якщо це правило забути, користувач системи здатна побачити документи іншої юридичної особи. Статус Це оптимізує не створювати дублікати. FROM orders * модель повторює таблицю без бізнес-сенсу; * у модель додали занадто багато логіки; * усі зв’язки зроблені eager loading; * усі зв’язки зроблені lazy loading; * немає індексів; * немає транзакцій; * немає soft delete; * немає аудиту; * немає обмежень доступу; * великі звіти будуються через ORM без оптимізації; * бізнес-логіка розкидана по контролерах, моделях і SQL. phone Зв’язок: * SELECT; * JOIN; * WHERE; * GROUP BY; * ORDER BY; * індекси; * транзакції; * блокування; * плани виконання; * нормалізацію; * обмеження цілісності; * оптимізацію запитів. !<pre> <pre> Кешування корисне для: '''Міграції бази даних''' — це контрольовані зміни структури таблиць. Що робить ORM У великій ERP такі обмеження мають бути централізованими, а не розкиданими по коду. |- | amount | Сума більше 0 |- | currency | Валюта обов’язкова |- | counterparty | Контрагент обов’язковий |- | contract | Договір обов’язковий |- | payment_date | Дата обов’язкова |} <pre>

ORM і продуктивність

• calculate_total;
• apply_discount;
• reserve_stock;
• change_status;
• cancel_order;
• create_invoice;
• check_credit_limit. lines

ORM і контрольні суми

! програміста це виглядає як робота з об’єктом забезпечується через ORM сам сформує SQL-запит до бази.; так само реалізовано а не з таблицею. {| class="wikitable" style="width:100%;" Power BI зазвичай не функціонує напряму з ORM-моделями. Поганий сценарій:

Приклад ORM для ERP-замовлення

• швидша розробка програмного забезпечення;
• менше ручного SQL;
• зрозуміліші моделі;
• повторне використання коду;
• зручна робота зі зв’язками;
• технічна підтримка транзакцій;
• міграції структури бази;
• валідація даних;
• інтеграційні функції ERP з API;
• краща читабельність бізнес-логіки.== ORM і зв’язки між таблицями ==

customer = Customer.get(id=15)
orders = Order.filter(organization=user.organization)
! ORM здатна використовуватися для перенесення даних, але з обережністю. Потрібно знати:

! Результат — зрозумілий код, швидша розробка програмного забезпечення, чистіші моделі, контроль транзакцій, зручні API, менше ручного SQL і краща технічна підтримка бізнес-логіки.[[Категорія:SQL]]

! {| class="wikitable" style="width:100%;"

В ERP ORM здатна використовуватися для роботи з основними бізнес-об’єктами. |-
| Customer
| має багато Order
| клієнт ERP має 25 замовлень
|-
| Order
| належить Customer
| Замовлення належить конкретному клієнту
|}

У коді ця таблиця здатна виглядати як клас:

через '''Головне.''' ORM користувачі можуть програмісту працювати з базою даних як з об’єктами: створити клієнта, знайти замовлення, змінити статус рахунку, зберегти платіж або отримати список товарів без ручного написання кожного SQL-запиту. ! Код стає ближчим до бізнес-логіки. | N+1 запити, повільна робота, зайве завантаження даних, неправильні індекси й слабкий контроль доступу. # Знайти дублікати.== ORM і безпека ==

! Data Mapper відокремлює об’єкти бізнес-логіки від механізму збереження. # Код створює або змінює об’єкт. N+1 — це ситуація, коли ORM виконує один запит для списку об’єктів і потім ще окремий запит для кожного об’єкта. Якщо одна дія не виконалась, потрібно відкотити всі інші.== Коли ORM підходить ==
У фінансах ORM здатна працювати з:
|-
| Кабель USB-C
| 100 шт. deal = Deal.create(

! У складі — товар. amount=50000,
|-
| Клієнти
| 12 450
| 12 450
| Збігається
|-
| Товари
| 8 200
| 8 198
| Потрібна перевірка
|-
| Замовлення
| 240 000
| 240 000
| Збігається
|-
| Платежі
| 95 000
| 94 990
| Потрібна перевірка
|}

Приклад в ERP:

external_order_id = "WEB-10425"

* SQL-запити;
* повільні запити;
* помилки транзакцій;
* помилки валідації;
* помилки міграцій;
* кількість запитів на сторінку;
* час виконання;
* користувача;
* API-запит;
* змінені об’єкти.== Приклад ORM в ERP ==

ORM зазвичай надає зручні методи для всіх цих операцій. id

! Customer

Правильно використаний ORM дає: orders = Order.filter(status="paid") Multi-tenant — це технічна архітектура, коли одна платформа обслуговує багато клієнтів або компаній. Сутність — це бізнес-об’єкт, який має значення для системи. Об’єкт

Ні. !

Крок Приклад моделі товару ORM і поля ORM у складській системі [[Категорія:ERP]] ORM зберігає угоду й пов’язує її з клієнтом. Перед вибором ORM варто оцінити: так само можна вести окремий журнал змін. quantity Але критично не перевантажувати ORM-моделі всією логікою. Дія ORM і eager loading total_amount ORM часто застосовується для за API. ! customer.email = "info@example.com" Частина бізнес-логіки здатна бути в моделях ORM. |- | Чи замінює ORM SQL?== ORM і аудит дій == == Приклад проблеми продуктивності == == ORM і моделі == == Приклад тесту бізнес-логіки == У фінансах — платіж.== Приклад валідації == * organization_id; * company_id; * tenant_id. customer = Customer.get(id=15) ! * один до одного; * один до багатьох; * багато до багатьох.== Приклад API + ORM == як приклад, модель ''Order'' здатна мати методи: [[Категорія:Права доступу]] Для звітів часто краще використовувати: <pre> Менеджер створює замовлення клієнта.== Приклад поганої ORM-моделі == WHERE status = 'paid'; {| class="wikitable" style="width:100%;" Для невеликих обсягів ORM зручний: * платежами; * банківськими рахунками; * касами; * валютами; * курсами; * договорами; * дебіторкою; * кредиторкою; * бюджетами; * статтями витрат; * заявками на оплату. * база виконує тисячі запитів; * сторінка відкривається 30 секунд; * сервер перевантажується; * користувачі думають, що ERP “гальмує”; * проблема насправді в неправильному використанні ORM. ORM не замінює SQL на 100%. # Зберегти зовнішній ID. # Записати аудит. Краще підготувати аналітичний запит або BI-модель. У великих ERP краще розділяти: Потрібно контролювати: конкурентні переваги правильного використання ORM створити платіжний документ; записати рух коштів; зменшити залишок банківського рахунку; закрити кредиторську заборгованість; оновити статус заявки; записати аудит дії. ! N+1 — одна з найвідоміших проблем ORM. status class OrderLine: CRUD-додатків; ERP-довідників; CRM-сутностей; адміністративних панелей; API; бізнес-документів; невеликих і середніх транзакцій; роботи з користувачами; роботи з ролями; операційних процесів. name Недоліки ORM: customer=customer, Такі перевірки допомагають не зберігати “биті” документи.== ORM і бізнес-логіка == як приклад: User має багато Role користувач системи виступає як менеджером і погоджувачем Role має багато User Роль “Менеджер” має 15 користувачів Один користувач системи бачить тільки документи ТОВ “компанія-користувач”. Сума
Створити	Customer.create(name="ТОВ Альфа")	Додає рядок у таблицю customers
Прочитати	Customer.get(id=10)	Виконує SELECT
Оновити	customer.phone = "+380..."	Готує UPDATE
Видалити	customer.delete()	Виконує DELETE або м’яке видалення

Міграція здатна виконати:

SET email = 'new@example.com'

! як приклад, API отримує запит:

• мову програмування;
• базу даних;
• складність доменної моделі;
• обсяг даних;
• вимоги до продуктивності;
• складність звітів;
• потребу в транзакціях;
• потребу в міграціях;
• досвід команди;
• підтримку індексів;
• підтримку raw SQL;
• інтеграцію з API;
• підтримку тестування.

* id; * number; * date; * customer_id; * status; * total_amount; * currency; * created_at; * updated_at. '''Транзакція''' — це група операцій, які мають виконатися разом або не виконатися взагалі. Для реальної ERP це має виконуватися в транзакції з перевіркою залишків. # Додати клієнта. | В ERP, CRM, сайтах, API, фінансових системах, складах, HRM, Service Desk і BI-рішеннях.<pre> У документообігу — договір. Перевіряють: == ORM і логування == ! customer.save() * модель Order описує інформаційні дані замовлення; * OrderService керує бізнес-логікою; * StockService відповідає за залишки; * PaymentService відповідає за оплати; * NotificationService надсилає повідомлення; * AuditService записує історію змін; * Repository відповідає за пошук і збереження. ALTER TABLE orders == ORM і багатокомпанійність == amount

Як функціонує ORM

У таких випадках можна комбінувати ORM із ручним SQL. |- | Які головні ризики?== ORM і multi-tenant системи ==

Eager loading — це попереднє завантаження пов’язаних даних. У ORM це можуть бути дві моделі:

Навіть якщо платформа використовує ORM, розробнику критично розуміти SQL. |- | object_type | SupplierBankAccount |- | object_id | 145 |- | action | update |- | user | buh01 |- | old_value | UA старий рахунок |- | new_value | UA новий рахунок |- | time | 15.05.2026 10:45 |}

У складі ORM здатна описувати:

ORM зручний для операційної роботи, але не завжди ідеальний для складної аналітики. ! ORM часто підтримує транзакції, щоб зберігати цілісність даних. | Ні, SQL усе одно потрібно розуміти для оптимізації, звітів, індексів і складних запитів. У системах інтеграції ORM здатна використовуватися для збереження зовнішніх даних. # Повернути номер документа. У базі це здатна бути таблиця:

ORM і валідація даних

! ! користувач системи змінив банківський рахунок постачальника. Правило

• Active Record;
• Data Mapper;
• Repository;
• Unit of Work;
• Entity Manager;
• Query Builder. ORM — це скорочення від Object-Relational Mapping, тобто об’єктно-реляційне відображення. Але для складної аналітики часто потрібні оптимізовані SQL-запити або BI-шар. Приклад

number

! Кращий сценарій:

Приклад з ORM

product

здатна перетворитися на SQL: orders = customer.orders ORM відповідає за перетворення між цими двома світами. Для великих обсягів краще використовувати: ! |- | Який результат? productRepository.findBySku("USB-C-1M-BLK") |- | Сайт | WEB-10425 | external_order_id |- | CRM | CRM-CUST-777 | external_customer_id |- | Банк | BANK-PAY-991 | external_payment_id |- | WMS | WMS-SHIP-2026 | external_shipment_id |}

Рядки замовлення:

== Приклад: звіт по маржі ==

!<pre>

payment = Payment.create(

<pre>

== ORM і індекси ==
== ORM і API ==
class Order:
|-
| number
| ORD-000145
|-
| customer
| ТОВ “клієнт ERP Плюс”
|-
| date
| 15.05.2026
|-
| status
| Нове
|-
| total
| 24 500 грн
|}

! У новій системі

 id

{| class="wikitable" style="width:100%;"
== ORM і кешування ==
При міграції через ORM критично рахувати контрольні суми. Один користувач системи здатна мати багато ролей, а одна роль здатна бути в багатьох користувачів. Типові ризики:

== Що потрібно знати перед вибором ORM ==

== Приклад аудиту ==

! як приклад, таблиця ''Customers'' здатна відповідати класу ''Customer'', таблиця ''Orders''.<pre>

== Приклад N+1 у продажах ==

== Приклад транзакції ==

=== Що таке N+1 проблема в ORM? ===
! | Для зручної роботи з даними: створення, читання, оновлення версій, видалення, зв’язків і транзакцій. unit

{| class="wikitable" style="width:100%;"

У кращому варіанті:

== ORM і SQL ==

 price

Запит має враховувати організацію:
<pre>
== Що таке ORM ==
! Приклад

[[Категорія:Впровадження ERP]]

! Що відбувається
Замовлення завантажуються тільки тоді, коли код звернувся до ''customer.orders''. ! А конкретний рядок таблиці стає об’єктом:

)

== ORM і soft delete ==

ORM-фреймворки часто мають власний механізм міграцій, щоб структура бази відповідала моделям у коді. ORM сам по собі не завжди вирішує права доступу, але здатна бути частиною механізму безпеки. Часто краще комбінувати ORM, bulk insert, ETL, SQL-запити й контрольні суми. як приклад, модель ''Order'' здатна мати поля:

* платформа отримала 100 клієнтів;
* потім для кожного клієнта окремо отримала його замовлення;
* замість 1–2 запитів до бази виконалось 101 запит. Приклад в ERP

!== Active Record ==

Приклад:

== Для чого потрібен ORM ==

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

date

Repository — це шаблон, який приховує деталі доступу до даних.== Коротко ==

• моделі даних;
• сервіси;
• бізнес-процеси;
• API;
• аналітику;
• права доступу. Зовнішній ID

• користувач системи бачить тільки свої замовлення;
• бухгалтер бачить документи своєї організації;
• комірник бачить тільки свій складський облік;
• менеджер не бачить собівартість;
• HR бачить тільки кадрові інформаційні дані;
• API-користувач здатна тільки читати залишки. |-

| price | decimal | 180.00 |- | active | boolean | true |}

Якщо це робити через ORM без оптимізації:

! # Прочитати контрагента з джерела. Тип

• створили замовлення;
• додали рядки;
• змінили залишки;
• створили резерв;
• записали аудит. Краще:

ORM здатна виконати такі дії:

Проблема N+1 запитів

ORM здатна автоматизовано заповнювати поля: ORM дає можливість описати ці сутності як об’єкти коду.== Приклад моделей Order і OrderLine ==

Приклад індексу

ORM часто застосовують, коли потрібно в ERP, CRM, e-commerce, фінансових системах, складських системах, HRM, Service Desk, BI-платформах, API та веб-додатках.

ORM функціонує як посередник між кодом і базою даних. | Чистіший код, швидша розробка програмного забезпечення, зручні моделі, контроль даних і простіша технічна підтримка бізнес-систем. як приклад, потрібно додати в замовлення поле delivery_status.== ORM і ліниве завантаження == stock.quantity = stock.quantity - 10 компанія-користувач проводить оплату постачальнику на 80 000 грн. ORM дає можливість описати ці зв’язки на рівні моделей. orderRepository.findPaidOrders()

Приклад міграції через ORM

У K2 ERP або подібній ERP-платформі ORM здатна використовуватися як технічний шар роботи з даними. платформа У різних мовах програмування існують свої ORM або ORM-подібні інструменти. ORM сам знайде замовлення цього клієнта. | Object-Relational Mapping — перетворення таблиць бази даних на об’єкти в коді. {| class="wikitable" style="width:100%;"

Приклади моделей в ERP:

• занадто багато SQL-запитів;
• N+1 проблема;
• зайве завантаження великих об’єктів;
• неправильні індекси;
• повільні JOIN;
• відсутність пагінації;
• завантаження всіх рядків одразу;
• складні фільтри без оптимізації;
• надмірні транзакції;
• повільні міграції. Поле в ORM-моделі

Customer	customers	Клієнти
Product	products	Номенклатура
Order	orders	Замовлення
Payment	payments	Платежі
Contract	contracts	Договори
User	users	Користувачі

Сайт створює замовлення через API. order = Order.get(number="10425")

Приклад:

• lead;
• contact;
• company;
• deal;
• task;
• call;
• email;
• note;
• pipeline;
• stage;
• user. # Додати рядки товарів. Питання

|- | id | integer | 101 |- | sku | text | USB-C-1M-BLK |- | name | text | Кабель USB-C 1 м чорний |- | unit | text | шт.== ORM і таблиці бази даних ==

• завантажити клієнтів разом із агрегованими продажами;
• використати JOIN;
• використати eager loading;
• використати окремий оптимізований SQL-запит;
• побудувати аналітичну таблицю. * замовлення не створюється без клієнта;
• рядок не здатна мати кількість 0;
• сума замовлення рахується правильно;
• статус не можна змінити з “скасовано” на “відвантажено”;
• замовлення не проводиться без товарів;
• резерв створюється тільки за наявності залишку. # ORM знає, якій таблиці відповідає модель. Відповідь

Запит:

ORM і сутності

stock = StockBalance.get(product=product, warehouse=warehouse)

stage="proposal"

ORM-моделі потрібно тестувати.

Що таке ORM простими словами?

• інформаційні дані замовлення;
• логіку знижок;
• логіку складу;
• логіку платежів;
• логіку доставки;
• логіку email;
• логіку PDF;
• логіку інтеграції з сайтом;
• логіку аналітики. Ризик:

як приклад:

Типовий ланцюг виглядає так:

Він оптимізує:

Що таке зв’язки в ORM?

Поширені помилки:

Приклад без ORM

У межах однієї транзакції платформа має:

Для підтримки ORM критично логувати:

Для платіжного документа можна задати правила:

Для чого потрібен ORM?

Зв’язки описують відношення між моделями: один клієнт ERP має багато замовлень, одне замовлення має багато рядків, користувач системи здатна мати багато ролей.

• як названі таблиці;
• чи виступає як зовнішні ID;
• чи виступає як статуси;
• чи виступає як аудит;
• чи немає дублів;
• чи правильно зберігаються зв’язки;
• чи виступає як created_at і updated_at;
• чи можна будувати інкрементальне оновлення версій. Це здатна зменшити кількість запитів і прискорити сторінку. * bulk insert;
• ETL;
• прямі SQL-запити;
• черги;
• пакетну обробку;
• контрольні суми. FROM customers

Це здатна бути складніше, але краще підходить для великих систем зі складною логікою. |-

клієнт ERP

id, name, phone, email

Це здатна сильно уповільнити ERP, CRM або інтернет-магазин. id

• не дивитися на SQL, який генерує ORM;
• завантажувати всі записи без фільтра;
• не використовувати пагінацію;
• ігнорувати N+1;
• не створювати індекси;
• не використовувати транзакції;
• видаляти інформаційні дані фізично без аудиту;
• зберігати бізнес-логіку хаотично;
• не тестувати міграції;
• використовувати ORM для всіх звітів без винятку;
• не контролювати права доступу.

== Unit of Work ==
ORM — це технологія, яка дає можливість працювати з таблицями бази даних як з об’єктами в коді.== ORM і формування звітів ==

== Приклад обмеження доступу ==

customer.name = "ТОВ клієнт ERP Плюс"

* ORM для бізнес-операцій;
* SQL для складної звітності;
* ETL для міграцій;
* кеш для довідників;
* черги для інтеграцій;
* API для зовнішніх систем;
* Power BI для аналітики;
* audit log для змін;
* окремі сервіси для складної логіки.== Repository ==

Якщо треба змінити email клієнта:

Приклади:

* організації;
* підрозділи;
* користувачі;
* ролі;
* контрагенти;
* договори;
* номенклатура;
* склади;
* замовлення;
* закупівельна діяльність;
* продажі та реалізація;
* платежі;
* залишки;
* бюджети;
* виробництво;
* сервісні заявки.

З ORM код здатна виглядати простіше:

UPDATE customers

ORM і тестування

Data Mapper

Для замовлення можна перевірити:

Звіт по маржі здатна потребувати:

Поля моделі відповідають колонкам таблиці.=== Який результат правильного використання ORM? === Індекси потрібні для швидкого пошуку за:

ORM і CRUD

• одне замовлення має багато рядків;
• кожен рядок належить одному замовленню;
• кожен рядок посилається на товар. Приклад

1. Отримати 500 клієнтів. |-

| Де застосовується для? * довідників;

• валют;
• одиниць виміру;
• ролей;
• налаштувань;
• типів документів;
• статусів;
• прав доступу;
• прайсів, якщо вони не змінюються щосекунди. Ціна

• Customer — клієнт ERP;
• Supplier — постачальник;
• Product — товар;
• Order — замовлення;
• Invoice — рахунок;
• Payment — платіж;
• Contract — договір;
• Warehouse — складський облік;
• Employee — працівник;
• User — користувач системи.== ORM не замінює SQL ==

* дуже складної аналітики;
* великих batch-операцій;
* масового імпорту мільйонів рядків;
* складних фінансових розрахунків;
* високонавантажених звітів;
* складних SQL-оптимізацій;
* ETL-процесів;
* систем реального часу з дуже високими вимогами до продуктивності. Customer
Unit of Work відстежує зміни об’єктів і зберігає їх разом. Кількість

* created_at;
* updated_at;
* created_by;
* updated_by;
* deleted_at;
* deleted_by. # Додати запис в аудит.== Простий приклад ORM ==

 counterparty=supplier,
 price
У результаті користувач системи не побачить залишки інших складів. # Записати результат міграції. Приклад

<div style="border:3px solid #1565c0; background:#e3f2fd; padding:14px; margin:16px 0;">

orders = Order.with(customer, lines).filter(status="paid")

* оптимізовані SQL-запити;
* матеріалізовані представлення;
* аналітичні таблиці;
* OLAP;
* BI-сховище;
* Power BI;
* окремі агрегати;
* ETL-процеси. як приклад:

[[Категорія:Міграція даних]]

 id

# Програміст описує модель.<pre>

* товар;
* складський облік;
* комірку;
* партію;
* серійний номер;
* залишок;
* переміщення;
* інвентаризацію;
* списання;
* резерв. # ORM повертає результат у вигляді об’єкта.== Коли ORM здатна бути поганим вибором ==

Можуть одночасно використовуватися:

ORM здатна працювати з кешем, щоб не запитувати одні й ті самі інформаційні дані багато разів. Це здатна сильно уповільнити систему. |-
| Для чого потрібен? | 130 грн
| 6 500 грн
|}

customer.save()

* Order;
* OrderLine. ORM генерує SQL або виконує запити до бази, але розробнику все одно потрібно розуміти SQL, індекси, транзакції, JOIN і продуктивність. | Моделі, сутності, таблиці, поля, зв’язки, запити, транзакції й міграції. Основні ризики — повільні запити, N+1 проблема, зайве завантаження даних, відсутність індексів, неправильні транзакції, слабка модель доступу й надмірна залежність від фреймворку. платформа має записати:

* клієнт ERP А здатна побачити інформаційні дані клієнта Б;
* API поверне чужі документи;
* Power BI отримає неправильний зріз;
* аудит стане некоректним.== FAQ ==

== Типові помилки при використанні ORM ==

* email має бути коректним;
* сума платежу не здатна бути від’ємною;
* замовлення має мати клієнта;
* товар має мати артикул;
* дата документа не здатна бути порожньою;
* статус має бути зі списку дозволених;
* кількість у рядку має бути більшою за нуль. Стало:

Приклад:

Якщо робити такий звіт тільки через ORM і завантажувати всі об’єкти, він здатна бути повільним. Він бере інформаційні дані з бази, API, файлів або сховища. Він генерує SQL або виконує запити до бази через власний механізм. customer = Customer.get(id=15)

* [[ERP]]
* [[K2 ERP]]
* [[API для ERP]]
* [[BI система]]
* [[Power BI]]
* [[CRM для продажів]]
* [[ERP для складу]]
* [[ERP для виробництва]]
* [[Казначейство]]
* [[Service Desk]]
* [[Права доступу в ERP]]
* [[Аудит дій]]
* [[Міграція даних]]
* [[Вивантаження даних]]
* [[Інтеграція з BAS]]
* [[ERP в хмарі]]
* [[Впровадження ERP]]
* [[Запуск ERP]]

Розробник здатна не писати SQL напряму, але має розуміти, які запити реально виконує ORM.== ORM у великих ERP-проєктах ==

Так, ORM добре підходить для багатьох ERP-операцій: довідників, документів, користувачів, ролей, замовлень, платежів, договорів і API. ! customer = Customer(name="ТОВ Альфа")

</div>

== ORM і помилки архітектури ==

== ORM і транзакції ==

{| class="wikitable" style="width:100%;"

* позначити товар неактивним;
* заборонити нові операції;
* залишити історію продажів;
* зберегти зв’язки в документах. SELECT id, name, email

! Приклад:

* продажі та реалізація;
* собівартість;
* знижки;
* повернення;
* валютні курси;
* договори;
* менеджерів;
* підрозділи;
* товарні групи. Active Record — це підхід, у якому модель сама вміє зберігати себе в базі. order

У цьому підході окремий шар відповідає за те, як об’єкти записуються в базу. ! Приклад
У CRM сутністю здатна бути клієнт ERP.</div>

! У реальних системах таблиці пов’язані між собою. Поля
У такому випадку ORM має дуже уважно фільтрувати інформаційні дані за tenant_id.

Це корисно для ERP, бо документи, договори, платежі й довідники часто не можна без зусиль видаляти без сліду. currency="UAH", Модель Customer одночасно виступає як і бізнес-об’єктом, і об’єктом доступу до бази. операційна дія

SEO title: ORM — Object-Relational Mapping, моделі, сутності, SQL, бази даних і ERP

SEO keywords: ORM, Object-Relational Mapping, об'єктно-реляційне відображення, ORM система, ORM приклади, SQL ORM, база даних ORM, моделі ORM, сутності ORM, транзакції ORM, міграції бази даних, ERP, K2 ERP

</noinclude>
 {{SEO
Шаблон для службового SEO-опису сторінки. 

}}

Приклад хорошої ORM-архітектури

Так, але для великих обсягів даних ORM здатна бути повільним. ! У старій системі

Основні конкурентні переваги ORM: Замість фізичного видалення рядка з бази ORM ставить ознаку:

amount=80000,

Unit of Work здатна зберегти все в межах однієї транзакції. ! # Перевірити ціни. Для інтеграцій критично зберігати зовнішні ідентифікатори. ORM-моделі можуть містити поле:

У базі даних ці самі інформаційні дані зберігаються в таблицях: Було:

ORM спрощує код, але здатна створювати приховані проблеми продуктивності. У ERP — документ, замовлення, рахунок, підрозділ або організація.

Недоліки ORM

ERP часто функціонує з кількома організаціями або компаніями. Код бізнес-логіки не знає, чи інформаційні дані прийшли з ORM, SQL, API або кешу. * замовлення з сайту; * клієнти з CRM; * платежі з банку; * залишки з WMS; * виробничі операції з MES; * статуси доставки; * документи ЕДО; * інформаційні дані для Power BI. # Створити резерв. Приклад багатокомпанійності ORM оптимізує отримати цей об’єкт із бази, змінити його й зберегти назад. ORM потрібен, щоб спростити роботу програми з базою даних. * сайт; * рекомендація; * маркетплейс; * виставка; * холодний дзвінок; * інтегратор. # Додати договори. ADD COLUMN delivery_status VARCHAR(50); * deleted = true; * deleted_at; * deleted_by. Зв’язок === Що таке модель в ORM? ===