ORM

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

Міграція має змогу виконати:

!; Приклад

lead;
contact;
company;
deal;
task;
call;
email;
note;
pipeline;
stage;
user.; !; # Знайти дублікати.; Поширені помилки:

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

ORM має змогу виконати такі дії:

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

FROM customers

stock.save()

quantity

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

 price

!; Приклади моделей в ERP:
stock = StockBalance.get(product=product, warehouse=warehouse)
[[Категорія:ORM]]
== переважні аспекти ORM ==
|-
| Кабель USB-C
| 100 шт.;== Недоліки ORM ==

Чи підходить ORM для ERP?

Прочитати контрагента з джерела.; ORM зазвичай надає зручні методи для всіх цих операцій.; платформа

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

ORM у фінансах

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

!;== ORM у міграції даних ==

ORM-фреймворки часто мають власний механізм міграцій, щоб структура бази відповідала моделям у коді.; Поле Транзакція — це група операцій, які мають виконатися разом або не виконатися взагалі.; !; Тип

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

Окремо варто відзначити тобто об’єктно-реляційне відображення.;== Приклад тесту бізнес-логіки == |- | Що таке ORM?; Таблиця в базі У великій ERP такі обмеження мають бути централізованими, а не розкиданими по коду.;<pre> class Order: як ілюстрація: Фізичне видалення небезпечне, бо старі документи втратять посилання.; # Закрити борг постачальника.; З ORM код має змогу виглядати простіше: <div style="border:3px solid #ef6c00; background:#fff3e0; padding:14px; margin:16px 0;"> == ORM і Power BI == У результаті користувач системи не побачить залишки інших складів.; Він генерує SQL або виконує запити до бази через власний механізм.; У CRM сутністю має змогу бути замовник.; Якщо неправильно будувати моделі, зв’язки й запити, ORM має змогу створювати повільні запити, дублювати інформаційні дані, перевантажувати сервер і приховувати помилки архітектури.; # Записати рух у регістр.;

Приклад багатокомпанійності

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

!; У складі ORM має змогу описувати:

Отримати 500 клієнтів.;== ORM і CRUD ==

!; phone

!; ORM часто підтримує роботу транзакції, щоб зберігати цілісність даних.;== Приклад ORM в ERP == як ілюстрація:

ORM і безпека

|- | замовник | id, name, phone, email, source_channel |}

Стало:

сайт;
рекомендація;
маркетплейс;
виставка;
холодний дзвінок;
партнерська сторона.;== ORM і сутності ==

ORM відповідає за перетворення між цими двома світами.; Відповідь

користувач системи має доступ тільки до складу №1.; !; У ORM це можуть бути дві моделі:

Перед вибором ORM варто оцінити:

amount

organization_id;
company_id;
tenant_id.; Було:

Що таке N+1 проблема в ORM?

Перевіряють:

order = Order.get(number="10425")

один до одного;
один до багатьох;
багато до багатьох.; Код стає ближчим до бізнес-логіки.; # Зберегти зовнішній ID.;== ORM і кешування ==

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

Сайт створює замовлення через API.; ORM зручний для операційної роботи, але не завжди ідеальний для складної аналітики.; CRUD — це базові операції з даними:
== ORM в CRM ==
ORM зберігає угоду й пов’язує її з клієнтом.; !; # Зберегти замовлення.; Поганий сценарій:

Який результат правильного використання ORM?

productRepository.findBySku("USB-C-1M-BLK")

Для цього в базі часто створюється проміжна таблиця: !; операційна дія external_order_id = "WEB-10425" Це комфортно, але має змогу створити проблему продуктивності.; * users;

roles;
user_roles.; orders = customer.orders

!; * приховані SQL-запити;

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

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

ORM і eager loading

ORM для бізнес-операцій;
SQL для складної звітності;
ETL для міграцій;
кеш для довідників;
черги для інтеграцій;
API для зовнішніх систем;
Power BI для аналітики;
audit log для змін;
окремі сервіси для складної логіки.; * модель Order описує інформаційні дані замовлення;
OrderService керує бізнес-логікою;
StockService відповідає за залишки;
PaymentService відповідає за оплати;
NotificationService надсилає повідомлення;
AuditService записує історію змін;
Repository відповідає за пошук і збереження.; Зовнішній ID

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

У великих ERP-проєктах ORM зазвичай не є собою єдиним способом роботи з даними.; | Чистіший код, швидша розробка програмного забезпечення, зручні моделі, контроль даних і простіша супровід бізнес-систем.; * оптимізовані SQL-запити;

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

істотно. ORM не скасовує SQL і не робить базу даних “простою автономно”.; stock.quantity = stock.quantity - 10

SELECT *

Але істотно не перевантажувати ORM-моделі всією логікою.; як ілюстрація:

Модель Order містить:

програміста це виглядає як робота з об’єктом забезпечується через ORM сам сформує SQL-запит до бази.; додатково реалізовано а не з таблицею.; # Створити Customer або Supplier.; |- | Які головні ризики?; orders = customer.orders

У коді це має змогу виглядати так: Міграції бази даних — це контрольовані зміни структури таблиць.; {| class="wikitable" style="width:100%;"

Без ORM програміст має змогу писати SQL вручну:

У системах інтеграції ORM має змогу використовуватися для збереження зовнішніх даних.; Приклад |- | User | має багато Role | користувач системи є собою менеджером і погоджувачем |- | Role | має багато User | Роль “Менеджер” має 15 користувачів |}

Потім потрібно вручну перетворити результат у структуру програми.;== Приклад проблеми продуктивності ==

CRUD-додатків;
ERP-довідників;
CRM-сутностей;
адміністративних панелей;
API;
бізнес-документів;
невеликих і середніх транзакцій;
роботи з користувачами;
роботи з ролями;
операційних процесів.;== Як функціонує ORM ==

phone

!; customer.save()

Приклад моделі товару

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

Але ORM впливає на якість даних:

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

У цьому підході окремий шар відповідає за те, як об’єкти записуються в базу.; Сутність

{{SEO

платформа отримала 100 клієнтів;
потім для кожного клієнта окремо отримала його замовлення;
замість 1–2 запитів до бази виконалось 101 запит.; * замовлення не створюється без клієнта;
рядок не має змогу мати кількість 0;
сума замовлення рахується правильно;
статус не можна змінити з “скасовано” на “відвантажено”;
замовлення не проводиться без товарів;
резерв створюється тільки за наявності залишку.; unit

як ілюстрація, потрібно додати в замовлення поле delivery_status.;== ORM і тестування == Так, ORM добре підходить для багатьох ERP-операцій: довідників, документів, користувачів, ролей, замовлень, платежів, договорів і API.; Для платіжного документа можна задати правила:

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

!; ORM сам по собі не завжди вирішує права доступу, але має змогу бути частиною механізму безпеки.;== Repository ==

Потрібно показати список клієнтів і суму їхніх замовлень.; Поля


Замовлення завантажуються тільки тоді, коли код звернувся до ''customer.orders''.;== ORM і інтеграції ==

orderRepository.findPaidOrders()

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

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

* calculate_total;
* apply_discount;
* reserve_stock;
* change_status;
* cancel_order;
* create_invoice;
* check_credit_limit.; | Object-Relational Mapping — перетворення таблиць бази даних на об’єкти в коді.; Типовий ланцюг виглядає так:
[[Категорія:Архітектура ПЗ]]
customer.name = "ТОВ замовник Плюс"

SELECT id, name, email

UPDATE customers

Потім повертає відповідь у JSON.; Така модель стає занадто великою й складною.; !; У складі — товар.; * deleted = true;

deleted_at;
deleted_by.; |-

Для чого потрібен?; class OrderLine: У K2 ERP або подібній ERP-платформі ORM має змогу використовуватися як технічний шар роботи з даними.; * created_at; updated_at; created_by; updated_by; deleted_at; deleted_by.; Приклад Customer — замовник; Supplier — постачальник; Product — товар; Order — замовлення; Invoice — рахунок; Payment — платіж; Contract — договір; Warehouse — складський облік; Employee — працівник; User — користувач системи.; * прочитати клієнтів; створити товари; перенести довідники; створити користувачів; перенести конфігурація.; # Перевірити залишки.; Це має змогу сильно уповільнити систему.;== Популярні ORM-підходи == У фінансах ORM має змогу працювати з:	; Часто краще комбінувати ORM, bulk insert, ETL, SQL-запити й контрольні суми.; ORM не замінює SQL в цілому.; Приклад customer=customer, Що потрібно знати перед вибором ORM Створити платіж.; customer.save() створення записів; актуалізація; видалення; зв’язки; транзакції; валідацію; обмеження доступу; поведінку при помилках; міграції; продуктивність запитів.; StockBalance.filter(warehouse=user.allowed_warehouse)	; # Додати запис в аудит.; # Записати аудит.; # ORM знає, якій таблиці відповідає модель.; Один замовник має змогу мати багато замовлень.; як ілюстрація: У документообігу — договір.; \| Для зручної роботи з даними: створення, читання, актуалізація, видалення, зв’язків і транзакцій.; ) ORM — це технологія, яка надає можливість працювати з таблицями бази даних як з об’єктами в коді.; email Він сприяє: amount=50000, ORM функціонує як посередник між кодом і базою даних.; orders = Order.filter(status="paid")	; id Приклад обмеження доступу currency="UAH",
amount	Сума більше 0
currency	Валюта обов’язкова
counterparty	Контрагент обов’язковий
contract	Договір обов’язковий
payment_date	Дата обов’язкова

Це надає можливість розділяти інформаційні дані між організаціями.; Ціна

orders = Order.filter(organization=user.organization)

customer = Customer.get(id=15)

Приклади: Приклади: Для замовлення можна перевірити: Це має змогу зменшити кількість запитів і прискорити сторінку.; Питання

Приклад в ERP:

!; Краще: ORM має змогу зменшити ризик SQL-ін’єкцій, якщо правильно використовувати параметризовані запити.; |- | Який результат?; Приклад в ERP

Data Mapper

створити платіжний документ;
записати рух коштів;
зменшити залишок банківського рахунку;
закрити кредиторську заборгованість;
оновити статус заявки;
записати аудит дії.; користувач системи видаляє товар, який уже був у продажах.; ORM має змогу виконати:

Якщо робити такий звіт тільки через ORM і завантажувати всі об’єкти, він має змогу бути повільним.; Для великих обсягів краще використовувати:

Data Mapper відокремлює об’єкти бізнес-логіки від механізму збереження.; !;

як ілюстрація, модель Order має змогу мати поля:

ORM і API

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

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

customer.email = "new@example.com"
customerRepository.findById(15)
|-
| id
| integer
| 101
|-
| sku
| text
| USB-C-1M-BLK
|-
| name
| text
| Кабель USB-C 1 м чорний
|-
| unit
| text
| шт.; Сума

FROM orders

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

ORM — це технологія, яка зв’язує об’єктну модель програми з реляційною базою даних.;== ORM і зовнішній ID ==

; Запит: SET email = 'new@example.com' ORM і індекси Зв’язок багато до багатьох
Створити	`Customer.create(name="ТОВ Альфа")`	Додає рядок у таблицю customers
Прочитати	`Customer.get(id=10)`	Виконує SELECT
Оновити	`customer.phone = "+380..."`	Готує UPDATE
Видалити	`customer.delete()`	Виконує DELETE або м’яке видалення

!;

ORM і SQL

Навіть якщо платформа використовує ORM, розробнику істотно розуміти SQL.; # База даних виконує запит.; ORM — це скорочення від Object-Relational Mapping.; !; Поле

Приклад API + ORM

організації;
підрозділи;
користувачі;
ролі;
контрагенти;
договори;
номенклатура;
склади;
замовлення;
закупівельна діяльність;
продажі та реалізація;
платежі;
залишки;
бюджети;
виробництво;
сервісні заявки.; # Створити об’єкт Order.;== ORM і валідація даних ==

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

counterparty=supplier,

Приклад:

Ризик:

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

Soft delete — це м’яке видалення.; Якщо це правило забути, користувач системи має змогу побачити документи іншої юридичної особи.; N+1 — одна з найвідоміших проблем ORM.; ORM сприяє отримати цей об’єкт із бази, змінити його й зберегти назад.; order |- | object_type | SupplierBankAccount |- | object_id | 145 |- | action | update |- | user | buh01 |- | old_value | UA старий рахунок |- | new_value | UA новий рахунок |- | time | 15.05.2026 10:45 |}

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

як ілюстрація, API отримує запит:

замовлення з сайту;
клієнти з CRM;
платежі з банку;
залишки з WMS;
виробничі операції з MES;
статуси доставки;
документи ЕДО;
інформаційні дані для Power BI.; # Повернути номер документа.; # ORM формує SQL-запит.; як ілюстрація, таблиця Customers має змогу відповідати класу Customer, таблиця Orders.; # ORM повертає результат у вигляді об’єкта.; !; У великих ERP краще розділяти:

id

Такі перевірки допомагають не зберігати “биті” документи.; !; * створювати записи;

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

Сайт	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

!; | Ні, SQL усе одно потрібно розуміти для оптимізації, звітів, індексів і складних запитів.; deal = Deal.create(

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

product

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

orders = Order.with(customer, lines).filter(status="paid") Приклад:

!;

У HRM — працівник.;== Приклад хорошої ORM-архітектури ==

contract=contract

У ERP — документ, замовлення, рахунок, підрозділ або організація.; |- | number | ORD-000145 |- | customer | ТОВ “замовник Плюс” |- | date | 15.05.2026 |- | status | Нове |- | total | 24 500 грн |}

Ні.;


* модель повторює таблицю без бізнес-сенсу;
* у модель додали занадто багато логіки;
* усі зв’язки зроблені eager loading;
* усі зв’язки зроблені lazy loading;
* немає індексів;
* немає транзакцій;
* немає soft delete;
* немає аудиту;
* немає обмежень доступу;
* великі звіти будуються через ORM без оптимізації;
* бізнес-логіка розкидана по контролерах, моделях і SQL.; Якщо ERP часто шукає замовлення за зовнішнім ID сайту:

Недоліки ORM:

організація проводить оплату постачальнику на 80 000 грн.; Сервер через ORM шукає замовлення:

* SQL-запити;
* повільні запити;
* помилки транзакцій;
* помилки валідації;
* помилки міграцій;
* кількість запитів на сторінку;
* час виконання;
* користувача;
* API-запит;
* змінені об’єкти.; Але для складної аналітики часто потрібні оптимізовані SQL-запити або BI-шар.;<pre>

додатково можна вести окремий журнал змін.; Краще підготувати аналітичний запит або BI-модель.;== ORM у складській системі ==

!; Зв’язок
Один користувач системи має змогу мати багато ролей, а одна роль має змогу бути в багатьох користувачів.; ORM надає можливість програмі працювати з даними бази не напряму через SQL-запити, а через об’єкти, класи, моделі і сутності в коді.;== ORM і міграції бази даних ==
Типові помилки:
Звіт по маржі має змогу потребувати:
<pre>

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

customer

Які ризики ORM?

Коли ORM підходить

FAQ

Модель — це клас або структура, яка описує інформаційні дані певного бізнес-об’єкта.; * id;

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

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

Приклади:

ORM надає можливість описати ці сутності як об’єкти коду.;


 status

Типові ризики:

* SELECT;
* JOIN;
* WHERE;
* GROUP BY;
* ORDER BY;
* індекси;
* транзакції;
* блокування;
* плани виконання;
* нормалізацію;
* обмеження цілісності;
* оптимізацію запитів.; | В ERP, CRM, сайтах, API, фінансових системах, складах, HRM, Service Desk і BI-рішеннях.; Що означає

Правильно використаний ORM дає:

* id;
* number;
* date;
* customer_id;
* status;
* total_amount;
* currency;
* created_at;
* updated_at.; У новій системі

[[Категорія:Права доступу]]

WHERE status = 'paid';

Приклад з ORM

ORM і soft delete

ORM і ліниве завантаження

; * продажі та реалізація; собівартість; знижки; повернення; валютні курси; договори; менеджерів; підрозділи; товарні групи.; # Записати результат міграції.; # Додати договори.;== Типові помилки при використанні ORM == Приклад без ORM інформаційні дані замовлення; логіку знижок; логіку складу; логіку платежів; логіку доставки; логіку email; логіку PDF; логіку інтеграції з сайтом; логіку аналітики.; customer = Customer(name="ТОВ Альфа") створили замовлення; додали рядки; змінили залишки; створили резерв; записали аудит.; \| 180 грн	18 000 грн
Зарядний адаптер	50 шт.; У CRM ORM має змогу працювати з такими сутностями: Що таке ORM total_amount ORM і аудит дій Але безпека залежить не тільки від ORM.; \|- \| Customer \| має багато Order \| замовник має 25 замовлень \|- \| Order \| належить Customer \| Замовлення належить конкретному клієнту \|} '''Практичний приклад.''' Замість SQL-запиту <code>SELECT * FROM orders WHERE customer_id = 15</code> ORM надає можливість написати щось схоже на <code>customer.orders</code> або <code>Order.findByCustomer(customer)</code>.;== Приклад валідації == price sku Замовлення клієнта має змогу містити шапку й рядки.; Основні переважні аспекти ORM: ADD COLUMN delivery_status VARCHAR(50); ORM надає можливість описати ці зв’язки на рівні моделей.;== Приклад індексу == ORM часто застосовується за API.; # Додати клієнта.; id stage="proposal" користувач системи змінив банківський рахунок постачальника.;</div> id Результат — зрозумілий код, швидша розробка програмного забезпечення, чистіші моделі, контроль транзакцій, зручні API, менше ручного SQL і краща супровід бізнес-логіки.; !; Значення ORM-моделі можуть містити поле: У програмі розробник функціонує з об’єктами: {\| class="wikitable" style="width:100%;" Power BI зазвичай не функціонує напряму з ORM-моделями.; як ілюстрація, замовник, товар або замовлення стають моделями програми.; # Додати рядки товарів.; Це сприяє не створювати дублікати.; Спочатку ORM отримує клієнта.; customer = Customer.get(id=15) == ORM і права доступу == У базі це має змогу бути таблиця: == ORM в ERP == == ORM і multi-tenant системи == Запит має враховувати організацію: {\| class="wikitable" style="width:100%;" == Приклад CRUD для клієнта == Потрібно знати: {\| class="wikitable" style="width:100%;" \|- \| Customer \| customers \| Клієнти \|- \| Product \| products \| Номенклатура \|- \| Order \| orders \| Замовлення \|- \| Payment \| payments \| Платежі \|- \| Contract \| contracts \| Договори \|- \| User \| users \| Користувачі \|} == переважні аспекти правильного використання ORM == !; !;== Приклад моделей Order і OrderLine == <pre> GET /api/orders/10425 == Пов’язані сторінки == як ілюстрація, модель ''Order'' має змогу мати методи: \|- \| 1 \| API отримує JSON із сайту \|- \| 2 \| ORM шукає клієнта по телефону \|- \| 3 \| ORM шукає товари по артикулу \|- \| 4 \| ORM створює замовлення \|- \| 5 \| ORM створює рядки замовлення \|- \| 6 \| платформа повертає номер замовлення \|} ORM часто надає можливість описувати правила перевірки даних.; Unit of Work відстежує зміни об’єктів і зберігає їх разом.; N+1 — це ситуація, коли ORM виконує один запит для списку об’єктів і потім ще окремий запит для кожного об’єкта.; \|- \| Create \| Створити запис \| Створити нового клієнта \|- \| Read \| Прочитати запис \| Відкрити замовлення \|- \| Update \| Оновити запис \| Змінити статус рахунку \|- \| Delete \| Видалити запис \| Видалити чернетку документа \|} Зв’язок: Якщо одна дія не виконалась, потрібно відкотити всі інші.;== Unit of Work == * customers; * orders; * invoices; * products; * payments; * users; * roles; * warehouses; * contracts; * documents.;== Для чого потрібен ORM == Active Record — це підхід, у якому модель сама вміє зберігати себе в базі.; то поле ''external_order_id'' має бути індексованим.; ORM має змогу допомагати працювати з: * замовник А має змогу побачити інформаційні дані клієнта Б; * API поверне чужі документи; * Power BI отримає неправильний зріз; * аудит стане некоректним.;=== Чи замінює ORM SQL? === [[Категорія:Power BI]] Частина бізнес-логіки має змогу бути в моделях ORM.; Крок !; Потрібно контролювати: У таких випадках можна комбінувати ORM із ручним SQL.; Поле в ORM-моделі <div style="border:3px solid #1565c0; background:#e3f2fd; padding:14px; margin:16px 0;"> ORM має змогу бути не найкращим варіантом для: class Product: == ORM і продуктивність == === Що таке модель в ORM? === Якщо треба змінити email клієнта: <pre> email Це корисно для ERP, бо документи, договори, платежі й довідники часто не можна без ускладнень видаляти без сліду.; == Коротко == завдяки наявності '''Головне.''' ORM користувачі можуть програмісту працювати з базою даних як з об’єктами: створити клієнта, знайти замовлення, змінити статус рахунку, зберегти платіж або отримати список товарів без ручного написання кожного SQL-запиту.; !;<pre> <pre> ORM спрощує код, але має змогу створювати приховані проблеми продуктивності.; \|- \| Що є собою основою ORM?; Приклад Для підтримки ORM істотно логувати: [[Категорія:Object-Relational Mapping]] Так, але для великих обсягів даних ORM має змогу бути повільним.; * моделі даних; * сервіси; * бізнес-процеси; * API; * аналітику; * права доступу.; '''Ліниве завантаження''' означає, що пов’язані інформаційні дані завантажуються тільки тоді, коли вони реально потрібні.; У фінансах — платіж.; # Перевірити ЄДРПОУ.; Краще винести частину логіки в сервіси.; !; WHERE id = 15; У бізнес-системах істотно знати, хто змінив інформаційні дані.; А конкретний рядок таблиці стає об’єктом: amount=80000, lines Для інтеграцій істотно зберігати зовнішні ідентифікатори.; \| Моделі, сутності, таблиці, поля, зв’язки, запити, транзакції й міграції.; number ORM пов’язує клас із таблицею.; Приклад дуже складної аналітики; великих batch-операцій; масового імпорту мільйонів рядків; складних фінансових розрахунків; високонавантажених звітів; складних SQL-оптимізацій; ETL-процесів; систем реального часу з дуже високими вимогами до продуктивності.;== ORM і K2 ERP == Це функціонує, але в великій ERP-системі таких запитів можуть бути тисячі.; \|-	Чи замінює ORM SQL?; ORM потрібен, щоб спростити роботу програми з базою даних.; !; Кількість * користувач системи бачить тільки свої замовлення; * бухгалтер бачить документи своєї організації; * комірник бачить тільки свій складський облік; * менеджер не бачить собівартість; * HR бачить тільки кадрові інформаційні дані; * API-користувач має змогу тільки читати залишки.; платформа має записати: '''Сутність''' — це бізнес-об’єкт, який має значення для системи.; name Інакше база має змогу переглядати тисячі або мільйони рядків.; * товар; * складський облік; * комірку; * партію; * серійний номер; * залишок; * переміщення; * інвентаризацію; * списання; * резерв.; * позначити товар неактивним; * заборонити нові операції; * залишити історію продажів; * зберегти зв’язки в документах.; {\| class="wikitable" style="width:100%;" Сторінка “продажі та реалізація за рік” відкриває всі документи реалізації, всі рядки, всіх клієнтів, всю номенклатуру й усі платежі.;== Коли ORM має змогу бути поганим вибором == == Active Record == ORM має змогу автономно заповнювати поля: Приклади: \|- \| 1 \| ТОВ “замовник Плюс” \| info@example.com \| +380XXXXXXXXX \|- \| 2 \| ФОП Іваненко \| ivanenko@example.com \| +380XXXXXXXXX \|} ) як ілюстрація: ORM має змогу працювати з кешем, щоб не запитувати одні й ті самі інформаційні дані багато разів.; Він бере інформаційні дані з бази, API, файлів або сховища.; Об’єкт ORM часто застосовується в ERP, CRM, e-commerce, фінансових системах, складських системах, HRM, Service Desk, BI-платформах, API та веб-додатках.; Сутність В ERP ORM має змогу використовуватися для роботи з основними бізнес-об’єктами.; Дія [[Категорія:API]] == Приклад міграції через ORM == Кешування корисне для: [[Категорія:ERP]] !; Товар * bulk insert; * ETL; * прямі SQL-запити; * черги; * пакетну обробку; * контрольні суми.; payment = Payment.create( {\| class="wikitable" style="width:100%;" Multi-tenant — це технічна архітектура, коли одна платформа обслуговує багато клієнтів або компаній.;=== Що таке ORM простими словами? === Приклад: * зрозумілий код; * швидшу розробку; * менше дублювання SQL; * стабільні моделі; * кращу підтримку API; * зручні міграції; * контроль транзакцій; * кращу тестованість; * простіше масштабування команди; * чистішу бізнес-логіку.; id <pre> {\| class="wikitable" style="width:100%;" як ілюстрація, одразу отримати замовлення разом із клієнтами й рядками: [[Категорія:Бази даних]] є собою таблиця клієнтів у базі даних.; name <pre> == ORM і бізнес-логіка == == Приклад аудиту == * Active Record; * Data Mapper; * Repository; * Unit of Work; * Entity Manager; * Query Builder.; * база виконує тисячі запитів; * сторінка відкривається 30 секунд; * сервер перевантажується; * користувачі думають, що ERP “гальмує”; * проблема насправді в неправильному використанні ORM.; Правило * одне замовлення має багато рядків; * кожен рядок належить одному замовленню; * кожен рядок посилається на товар.; # Для кожного клієнта окремо запитати замовлення.; * не дивитися на SQL, який генерує ORM; * завантажувати всі записи без фільтра; * не використовувати пагінацію; * ігнорувати N+1; * не створювати індекси; * не використовувати транзакції; * видаляти інформаційні дані фізично без аудиту; * зберігати бізнес-логіку хаотично; * не тестувати міграції; * використовувати ORM для всіх звітів без винятку; * не контролювати права доступу.; \| N+1 запити, повільна робота, зайве завантаження даних, неправильні індекси й слабкий контроль доступу.; !; Зв’язок !; {\| class="wikitable" style="width:100%;" [[Категорія:Аудит дій]] == ORM і логування == class Customer: Індекси потрібні для швидкого пошуку за: == ORM і помилки архітектури == ALTER TABLE orders == ORM і таблиці бази даних == * довідників; * валют; * одиниць виміру; * ролей; * налаштувань; * типів документів; * статусів; * прав доступу; * прайсів, якщо вони не змінюються щосекунди.; \|} Приклад: Це має змогу сильно уповільнити ERP, CRM або інтернет-магазин.; * замовник; * замовлення; * рахунок; * товар; * платіж; * користувач системи; * роль; * складський облік; * договір; * документ.; У контексті [[K2 ERP]] ORM має змогу бути частиною серверної логіки, яка функціонує з довідниками, документами, користувачами, ролями, замовленнями, платежами, залишками, договорами, номенклатурою та аналітичними даними.; '''Eager loading''' — це попереднє завантаження пов’язаних даних.; Поля date <pre> Для реальної ERP це має виконуватися в транзакції з перевіркою залишків.; Статус Після міграції можна аналізувати, звідки прийшов замовник: У базі це будуть колонки таблиці ''orders''.; name == ORM і моделі == Поля моделі відповідають колонкам таблиці.; Модель ''Customer'' одночасно є собою і бізнес-об’єктом, і об’єктом доступу до бази.; Код бізнес-логіки не знає, чи інформаційні дані прийшли з ORM, SQL, API або кешу.; ORM генерує SQL або виконує запити до бази, але розробнику все одно потрібно розуміти SQL, індекси, транзакції, JOIN і продуктивність.; Для звітів часто краще використовувати: == Простий приклад ORM == !; У коді ця таблиця має змогу виглядати як клас: ORM має змогу використовуватися для перенесення даних, але з обережністю.; Типові зв’язки: класу ''Order'', а рядок у таблиці — конкретному об’єкту в коді виступає ключовою рисою Простіше кажучи, ORM перетворює таблиці бази даних на об’єкти програми.; Замість фізичного видалення рядка з бази ORM ставить ознаку: == ORM не замінює SQL == ERP часто функціонує з кількома організаціями або компаніями.; \|- \| price \| decimal \| 180.00 \|- \| active \| boolean \| true \|} !; # Створити резерв.; Менеджер створює замовлення клієнта.; \|-	Клієнти	12 450	12 450	Збігається
Товари	8 200	8 198	Потрібна перевірка
Замовлення	240 000	240 000	Збігається
Платежі	95 000	94 990	Потрібна перевірка

Основні ризики — повільні запити, N+1 проблема, зайве завантаження даних, відсутність індексів, неправильні транзакції, слабка модель доступу й надмірна залежність від фреймворку.; Для невеликих обсягів ORM зручний:

Але кеш потрібно правильно оновлювати, інакше користувачі бачитимуть старі інформаційні дані.; WHERE id = 15;

Repository — це шаблон, який приховує деталі доступу до даних.; У такому випадку ORM має дуже уважно фільтрувати інформаційні дані за tenant_id.; як ілюстрація, модель Product має змогу відповідати таблиці products.; |- | Де застосовується?; Кращий сценарій:

ORM сам знайде замовлення цього клієнта.; Customer Unit of Work має змогу зберегти все в межах однієї транзакції.; active

Якщо помилка сталася на етапі закриття боргу, платіж не повинен залишитися “наполовину проведеним”.; У кращому варіанті:

!; # Код створює або змінює об’єкт.; Один користувач системи бачить тільки документи ТОВ “організація”.; ORM потрібен, щоб швидше й зручніше створювати, читати, оновлювати й видаляти інформаційні дані без ручного написання кожного SQL-запиту.; !; # Отримати 501 запит до бази.;=== Чи можна використовувати ORM для міграції даних? ===

завантажити клієнтів разом із агрегованими продажами;
використати JOIN;
використати eager loading;
використати окремий оптимізований SQL-запит;
побудувати аналітичну таблицю.; | 130 грн

| 6 500 грн |}

як ілюстрація, код:

Order;
OrderLine.; У старій системі

У різних мовах програмування існують свої ORM або ORM-подібні інструменти.; Об’єкт у коді customer = Customer.get(id=15)

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

Потрібно перенести список контрагентів у нову ERP.; має змогу перетворитися на SQL:

ORM і зв’язки між таблицями

!; Що робить ORM

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

як ілюстрація:

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

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

ORM у великих ERP-проєктах

замовник	id, name, phone, email

Модель — це клас або структура в коді, яка відповідає таблиці бази даних.; # Перевірити ціни.;== Приклад транзакції ==

організація хоче додати в модель клієнта поле “канал залучення”.;== Приклад міграції ==

ORM і формування звітів

customer.email = "info@example.com"