CRUD
Основні ризики:
Але CRM так само має бізнес-логіку: історія продукту взаємодії, права менеджерів, етапи продажу, нагадування, автоматизація процесів, звіти.== CRUD і CRM ==
- відкрити список товарів;
- переглянути картку клієнта;
- подивитися документ;
- відкрити звіт;
- знайти замовлення;
- переглянути історію змін;
- завантажити файл;
- отримати інформаційні дані через API;
- переглянути CRM-активність;
- відкрити конфігурація. Update
- створити документ — це не без зусиль Create;
- прочитати звіт — це не без зусиль Read;
- змінити проведений документ — це не без зусиль Update;
- видалити товар — це не без зусиль Delete.== CRUD і Frontend ==
|- | Адміністратор | Так | Так | Так | Так |- | Бухгалтер | Так | Так | Так | Обмежено |- | Менеджер | Так | Так | Обмежено | Ні |- | складський облік | Обмежено | Так | Обмежено | Ні |- | Гість | Ні | Обмежено | Ні | Ні |}
Audit log або журнал аудиту — запис того, хто, коли й що зробив із даними. {| class="wikitable" style="width:100%;" У такій архітектурі CRUD має бути ізольованим за tenant або компанією. HTTP-метод
CRUD і Cloud Computing
- обов’язкове поле заповнене;
- email має правильний формат;
- ціна не від’ємна;
- кількість більша за нуль;
- дата в допустимому періоді;
- користувач системи має доступ до компанії;
- документ не в закритому періоді;
- файл має дозволений тип;
- API-запит має правильну структуру. Приклад
як приклад, менеджер створює ліда, переглядає його картку, оновлює статус і здатна архівувати неактуальний контакт.
Джерела
хмарна інфраструктура K2 ERP доступна за адресою:
- чи документ можна редагувати;
- чи він уже проведений;
- чи період закритий;
- чи користувач системи має право;
- чи зміна вплине на залишки;
- чи потрібно створити історію;
- чи треба повідомити інтеграцію;
- чи можна змінювати суму після фіскалізації;
- чи треба перерахувати звіт. Приклади:
- створювати їх;
- показувати їх потрібним людям;
- змінювати контрольовано;
- видаляти або архівувати безпечно;
- вести історію;
- захищати права;
- підтримувати API;
- масштабуватися;
- працювати в хмарі. Тести мають перевіряти:
- хто створив запис;
- хто переглянув важливі інформаційні дані;
- хто змінив запис;
- які поля змінив;
- хто видалив або архівував запис;
- коли це сталося;
- з якого пристрою або IP;
- яка була роль користувача. * тестових даних;
- тимчасових записів;
- технічних об’єктів;
- очищення системи;
- виконання вимог приватності;
- видалення непотрібних файлів. Особливо критично не робити небезпечні дії надто легкими. ! Деколонізація обліку — це не тільки відмова від 1С та BAS. |-
| Чому Delete небезпечний? |- | Яка головна небезпека CRUD? * яка операційна дія: Create, Read, Update або Delete;
- який компонент;
- який запис;
- яка роль користувача;
- які кроки виконувалися;
- очікуваний результат;
- фактичний результат;
- чи повторюється проблема;
- чи виступає як скриншот;
- чи виступає як номер документа або ID запису;
- чи проблема в браузері, API або мобільному застосунку. Українською
Це так само перехід до нової культури даних: Concurrency — одночасна робота кількох користувачів або процесів із тими самими даними. Критично. CRUD-права мають перевірятися на backend. * видалити чернетку документа;
- видалити непотрібний товар;
- видалити контакт;
- видалити файл;
- видалити тестовий запис;
- видалити конфігурація;
- видалити API-токен;
- видалити користувача або заблокувати його. Видалити. | ERP функціонує з бізнес-даними: документами, товарами, клієнтами, файлами, звітами, ролями й компаніями. Сила ERP у тому, що вона робить це контрольовано, безпечно й відповідно до бізнес-логіки. Такий підхід робить систему гнучкішою, але потребує контролю типів, прав, валідації й впливу на звіти. У K2 ERP Create здатна означати створення нового бізнес-об’єкта: товару, контрагента, документа, компанії, CRM-запису, файлу або іншої сутності. ERP потребує CRUD плюс правила, перевірки й процеси. В ERP CRUD завжди пов’язаний із обліком. Змінює ціну або SEO-опис. Хмарний CRUD має враховувати:
Приклади Delete: Read здається найменш небезпечною операцією, але це не так. # Додавати pagination для списків. # Перевіряти права на backend. ! # Додавати audit log для важливих змін. У backend CRUD реалізує серверну логіку роботи з даними. користувач системи має бачити:
Суть поняття
Типові проблеми CRUD
Це і виступає як CRUD. ! # Реалізовувати soft delete там, де потрібна історія продукту. Недоліки:
Для ФОП на єдиному податку CRUD здатна проявлятися в простих і зрозумілих діях:
CRUD і звіти
- лідів;
- клієнтів;
- контактів;
- угод;
- задач;
- дзвінків;
- листів;
- нотаток;
- активностей;
- статусів;
- воронок продажів. Погана cache invalidation здатна призвести до того, що користувач системи бачить старі інформаційні дані після CRUD-операції. Тому в ERP часто замість фізичного видалення використовують архівацію, деактивацію або soft delete.== Update ==
- користувач системи створює запис у чужій компанії;
- користувач системи читає чужі інформаційні дані;
- користувач системи змінює документ без права;
- користувач системи видаляє важливі записи;
- API дає можливість масові зміни;
- немає audit log;
- немає валідації;
- frontend приховує кнопку, але backend дає можливість дію;
- ID запису можна підставити вручну;
- soft delete не захищає від перегляду. як приклад:
Для ERP soft delete часто безпечніший за фізичне видалення. # Перевіряти вплив на звіти. Для bug report CRUD-проблему потрібно описувати чітко. CRUD часто застосовується для в налаштуванні ролей доступу. як приклад:
! Прочитати. Питання
CRUD-операції мають бути продуктивними. Роль
як приклад, CRUD каже: «Оновити документ». * Code
- Backend
- Frontend
- API
- Database
- SQL
- REST
- Authentication
- Authorization
- Cache
- Bug
- Bug report
- Code Review
- Testing
- Cloud Computing
- Automation
- Algorithm
- ERP
- CRM
- ФОП
- Єдиний податок
- K2
- K2 ERP
- K2 ERP технологічна платформа
- Українське програмне забезпечення
- Деколонізація обліку
- Цифрова незалежність України
Корисно вказати:
- хмарна інфраструктура K2 ERP
- офіційний сайт K2
- Статті про K2 ERP
- Wiki K2 ERP
- LinkedIn K2 ERP
- Telegram-канал K2 ERP
- Група обговорення K2 ERP
як приклад:
Стара культура: «виправ у базі напряму, тільки нікому не кажи». Відповідь Це інтуїтивно для стандартних сутностей. «Що користувач системи або платформа здатна робити з даними?»
REST API часто має зрозумілу структуру:
CRUD і REST
- після Create список має оновитися;
- після Update кешований запис має змінитися;
- після Delete запис не має залишитися в кеші;
- після зміни прав доступу кеш прав має очиститися;
- після зміни документа звіт має оновитися. За потреби видаляє або архівує запис. * як створити запис;
- які поля обов’язкові;
- що змінено;
- коли інформаційні дані збережені;
- чи виступає як помилки;
- чи можна скасувати дію;
- що буде після видалення;
- чи запис архівується;
- чи виступає як підтвердження;
- чи дія незворотна. Проблема
У frontend CRUD проявляється як інтерфейс користувача:
CRUD і історія продукту змін
Приклад:
- користувачі;
- клієнти;
- товари;
- замовлення;
- документи;
- файли;
- задачі;
- коментарі;
- ролі;
- конфігурація;
- довідники;
- категорії;
- характеристики;
- звіти;
- інтеграції. * створює нові записи;
- оновлює існуючі;
- перевіряє інформаційні дані;
- показує помилки;
- здатна створювати дублікати, якщо зроблений погано. # Забезпечити відновлення помилково видалених даних, якщо це можливо. ! як приклад, для модуля «Товари» можна дозволити:
- створення запису;
- читання доступних даних;
- заборону читання чужих даних;
- оновлення версій;
- заборону оновлення версій без прав;
- видалення;
- soft delete;
- валідацію;
- помилки;
- транзакції;
- concurrency;
- API;
- frontend-форму. Якщо хтось випадково видалив або масово змінив інформаційні дані, backup здатна бути останньою лінією захисту. В API CRUD часто відповідає HTTP-методам. Не кожен запис можна безпечно видалити, особливо якщо він уже застосовують, коли потрібно в документах, звітах або інтеграціях. У K2 ERP CRUD-операції можуть застосовуватися до багатьох сутностей:
- optimistic locking;
- pessimistic locking;
- версії записів;
- перевірка актуальності;
- повідомлення користувачу;
- черги задач. У найпростішому сенсі CRUD відповідає на питання:
Delete
У ERP імпорт/експорт має бути контрольованим, бо через нього можна оперативно змінити багато даних. !== CRUD і продуктивність ==
Read |
У базах даних, backend, frontend, API, ERP, CRM, хмарних сервісах і мобільних застосунках. У контексті K2 ERP CRUD-операції лежать в основі роботи з товарами. Українські бізнес-системи мають якісно працювати з даними:
Рекомендації для розробників |
Тобто CRUD-модель тут недостатня без бізнес-правил. У ERP транзакції критично важливі. У контексті РРО/ПРРО CRUD має специфіку.== CRUD і база даних == У бізнес-системах audit log дуже важливий. Read
| |
|---|---|---|---|
| C | Create | Створити | Створити нового клієнта або документ |
| R | Read | Прочитати / переглянути | Відкрити картку товару або список документів |
| U | Update | Оновити / змінити | Змінити адресу клієнта або ціну товару |
| D | Delete | Видалити | Видалити чернетку документа або непотрібний запис |
CRUD і характеристики
CRUD і Cache
CRUD в ERP
| Немає перевірки прав на backend | користувач системи здатна виконати заборонену дію | Перевіряти authorization на сервері |
| Немає валідації | У базу потрапляють некоректні інформаційні дані | Валідовувати frontend і backend |
| Hard delete важливих записів | Ламаються зв’язки й історія продукту | Використовувати soft delete або архів |
| Немає audit log | Незрозуміло, хто змінив інформаційні дані | Вести журнал змін |
| Немає транзакцій | інформаційні дані можуть зберегтися частково | Використовувати транзакції |
| Немає пагінації | Списки працюють повільно | Додавати pagination і фільтри |
| Немає захисту tenant | Ризик показати чужу компанію | Фільтрувати інформаційні дані за компанією або tenant |
| Небезпечне масове оновлення версій | Можна зіпсувати багато записів | Додавати підтвердження, логи, rollback |
Update у бізнес-системах особливо важливий, бо зміни можуть впливати на обліковий облік, документи, звіти, інтеграції й історію. # Вести історію змін.== Create ==
Авторизація визначає, які CRUD-операції дозволені користувачу.CRUD і ФОП на єдиному податку
Тобто CRUD виступає як базою, але ERP часто потребує більш детальних дій. Приклад:
CRUD — абревіатура від Create, Read, Update, Delete, тобто чотирьох базових операцій над даними:
У ERP GraphQL або інші гнучкі API потрібно захищати, щоб користувач системи не міг отримати зайві інформаційні дані через надто широкі запити. * читає інформаційні дані;
- формує файл;
- враховує права;
- здатна містити конфіденційну інформацію. Особливо для документів забезпечується через У ERP історія продукту змін потрібна; так само реалізовано цін, доступів, клієнтів, товарів і фінансових полів. ERP має враховувати:
Добрі практики: користувач системи не повинен бачити чужу компанію, фінансові звіти без прав, персональні інформаційні дані без дозволу або документи іншого підрозділу. * створити товар;
- створити продаж;
- переглянути документи;
- оновити клієнта;
- прикріпити файл;
- сформувати звіт;
- змінити конфігурація;
- архівувати неактуальний запис. |-
- відсутність пагінації;
- пошук без індексів;
- update великої кількості записів;
- delete без перевірки зв’язків;
- API повертає забагато даних;
- frontend завантажує все одразу;
- немає cache;
- база даних перевантажена. Backend не має без зусиль виконувати CRUD «як попросили». * Create — створити;
- Read — прочитати або переглянути;
- Update — оновити або змінити;
CRUD і API
як приклад:
Backup не виступає як CRUD-операцією, але він захищає від помилок CRUD. Це означає, що CRUD має бути гнучким, але контрольованим. | Create, Read, Update, Delete — створення, читання, оновлення версій та видалення даних. |}
CRUD і UX
GraphQL дає можливість клієнту гнучко запитувати потрібні поля, але потребує уважного контролю доступів і продуктивності. Після цього вже функціонує авторизація: що саме цьому користувачу дозволено. * можна відновити запис;
- зберігається історія продукту;
- не ламаються зв’язки;
- легше провести аудит;
- менше ризик випадкової втрати. | Виконання операцій без перевірки прав, історії, валідації та бізнес-правил. | Ні. # Враховувати компанії та підприємства. UX для CRUD має бути зрозумілим.
Reviewer має звертати увагу:
CRUD і Bug
Створити. | Видалення здатна зламати історію, зв’язки, звіти або обліковий облік. # Тестувати заборонені дії. Змінити проведений документ заднім числом — зовсім інше. Обережно з Delete. У ERP видалення даних має бути контрольованим. Кнопка «Видалити все» не повинна виглядати як дружня зелена кнопочка поруч із «Зберегти». Delete
Для SQL це часто виглядає так:
CRUD і Soft Delete
CRUD і РРО/ПРРО
- запис заголовка документа;
- запис рядків документа;
- оновлення версій залишків;
- запис історії;
- створення рухів;
- оновлення версій статусу;
- логування. Ресурсами можуть бути:
Нова культура: «операційна дія має пройти через систему, права, журнал, валідацію й бізнес-логіку». CRUD — це технічна модель. Але сила ERP не в тому, що вона без зусиль дає можливість створювати й редагувати записи. * Create — завантажити файл;
- Read — переглянути або завантажити файл;
- Update — замінити файл або змінити SEO-опис;
- Delete — видалити або архівувати файл. Soft Delete — м’яке видалення, коли запис не видаляється фізично з бази, а позначається як видалений, неактивний або архівний. Якщо одна частина не вдалася, транзакція має відкотитися, щоб не залишити систему в напівзламаному стані. довіри до даних. Для модуля «Документи» права можуть бути детальнішими:
Переглядає картку товару. історія продукту змін показує, як саме змінювався запис. |-
Що таке soft delete? # Не дозволяти редагувати проведені документи без правил. # Розділяти технічний CRUD і бізнес-операції.Але створення — це не без зусиль «додати рядок у базу». Як краще
Frontend має бути зручним, але не здатна бути єдиним захистом. У K2 ERP виступає як можливість розширення сутностей за рахунок характеристик. користувач системи відкриває браузер, frontend надсилає запит до backend, backend звертається до бази даних, виконує CRUD-операцію й повертає результат. Документ не має зберегтися наполовину. Його створення здатна змінювати залишки, статуси, звіти й інтеграції.== Висновок ==
CRUD і multi-tenant технічна архітектура
CRUD і безпека
- два користувачі редагують один документ;
- інтеграційні функції ERP оновлює товар, поки менеджер змінює ціну;
- API створює замовлення, а складський облік змінює залишки;
- два процеси списують один і той самий товар.
- змінити назву товару;
- оновити ціну;
- змінити адресу клієнта;
- відредагувати документ;
- змінити статус замовлення;
- оновити роль користувача;
- додати характеристику;
- змінити конфігурація компанії;
- оновити контакт у CRM;
- змінити файл або SEO-опис. як приклад, створення документа здатна включати перевірку прав, валідацію, транзакцію, рухи товарів, історію змін, журналювання, інтеграції та перерахунок звітів. * затримку мережі;
- API;
- авторизацію;
- сесії;
- cache;
- одночасну роботу;
- масштабування;
- логи;
- backup;
- безпеку;
- роботу багатьох компаній. Створює новий товар. {| class="wikitable" style="width:100%;"
Але краще не доводити до аварійного відновлення. | POST, GET, PUT/PATCH, DELETE. SQL
Create INSERT Додати новий товар Read SELECT Отримати список клієнтів Update UPDATE Змінити ціну товару Delete DELETE Видалити записCRUD-код здається стандартним, тому його швидко недооцінити. Приклад в ERP
Hard Delete — фізичне видалення запису з бази даних. CRUD для характеристик здатна включати: Update — операційна дія оновлення версій або зміни існуючого запису. | INSERT, SELECT, UPDATE, DELETE. У K2 ERP уже готовий обліковий облік для ФОП на єдиному податку, тому CRUD-операції мають бути простими для користувача, але коректними з погляду обліку.== CRUD і GraphQL ==
- створити документ саме в потрібній компанії;
- читати інформаційні дані лише дозволених компаній;
- оновлювати записи лише у своїй області доступу;
- не видаляти інформаційні дані іншої компанії;
- не змішувати звіти;
- не показувати клієнтів чужої компанії. Документ продажу — це не без зусиль запис. Це одразу показує операцію, компонент, роль і проблему доступу. Не все, що технічно можна змінити в базі, дозволено змінювати в обліку. * запис створюється без обов’язкового поля;
- користувач системи бачить чужі інформаційні дані;
- редагування не зберігається;
- видалення не перевіряє права;
- API повертає старі інформаційні дані;
- soft delete не приховує запис;
- hard delete ламає зв’язки;
- update перезаписує інформаційні дані іншого користувача;
- список не оновлюється після створення. Але в ERP hard delete потрібно використовувати дуже обережно. * читати багато даних;
- агрегувати;
- фільтрувати;
- сортувати;
- кешувати;
- експортувати;
- формувати файл;
- запускатися у фоні. Проблеми:
CRUD і Backend
Файли так само можуть мати CRUD-операції:
Помилка в multi-tenant CRUD здатна бути критичною, бо здатна відкрити інформаційні дані однієї компанії іншій. * створити клієнта;
- створити товар;
- створити документ;
- створити рахунок;
- створити замовлення;
- створити користувача;
- створити компанію;
- створити файл-вкладення;
- створити характеристику;
- створити запис CRM;
- створити API-токен;
- створити задачу.
- users;
- products;
- customers;
- orders;
- documents;
- files;
- companies;
- roles;
- reports. |-
| Які SQL-операції відповідають CRUD? * права доступу;
- транзакції;
- логування;
- обробка помилок;
- частковий успіх;
- rollback;
- продуктивність;
- обмеження розміру.
Розшифрування CRUD
Фраза «воно саме змінилося» має закінчуватися не суперечкою в чаті, а відкриттям журналу змін. |-
| Де застосовується для CRUD? Це аналітична операційна дія, яка здатна навантажувати CPU, базу даних і cache.Multi-tenant технічна архітектура означає, що одна платформа здатна обслуговувати багато клієнтів, компаній або організацій. ! Але бізнес-дії можуть виходити за межі CRUD. платформа має перевірити права, обов’язкові поля, унікальність, зв’язки, формат даних і бізнес-правила. # Не реалізовувати CRUD без авторизації. Read — операційна дія читання або перегляду даних.== CRUD і Hard Delete ==
- pagination;
- фільтри;
- індекси;
- обмеження полів;
- lazy loading;
- batch operations;
- background jobs;
- caching;
- оптимізовані SQL-запити. | М’яке видалення, коли запис позначається як видалений або архівний, але фізично не зникає. Бізнес-логіка — це правила реального процесу. | K2 ERP використовує CRUD для роботи з товарами, документами, CRM, компаніями, файлами, довідниками, характеристиками й іншими сутностями.== CRUD і багатокомпанійність ==
Приклади Read:
У модулі “Товари” користувач системи із роллю “Менеджер” здатна видалити товар, хоча для цієї ролі Delete має бути заборонений.
конкурентні переваги soft delete:
Batch operations — пакетні операції над багатьма записами. Це дисципліна цілісності даних.== CRUD і бізнес-логіка ==
Batch CRUD потребує особливої обережності:
- кнопка «Створити»;
- список записів;
- форма перегляду;
- форма редагування;
- кнопка «Зберегти»;
- кнопка «Видалити»;
- пошук;
- фільтри;
- таблиці;
- картки об’єктів;
- підтвердження дій. Окремо варто відзначити клієнтами, документами, компаніями, CRM, файлами, довідниками, звітами, ролями, характеристиками, інтеграціями і іншими сутностями системи. Приклад endpoint
Інтеграції часто виконують CRUD через API. * хто робить запит;
- чи користувач системи увійшов у систему;
- чи сесія активна;
- чи токен дійсний;
- чи не заблокований користувач системи;
- чи не завершився доступ.Code Review має перевіряти CRUD-логіку. Якщо запис уже пов’язаний із документами, звітами або історією, фізичне видалення здатна зламати цілісність даних. Для CRUD це означає:
як приклад, API для товарів здатна дозволяти:
Видалення здатна зламати зв’язки, історію, звіти, документи або інтеграції. # Очищати cache після змін. # Тестувати Create, Read, Update і Delete окремо. Не спрощуйте CRUD у ERP. Якщо платформа дає можливість створювати, змінювати або видаляти бізнес-дані без правил і журналу змін, це не гнучкість, а ризик для обліку. Застереження. CRUD здається простим лише на перший погляд. Create
У системі, де один користувач системи або адміністратор здатна працювати з кількома компаніями, CRUD має враховувати контекст компанії. {| class="wikitable" style="width:100%;"
Перед виконанням CRUD-операції платформа має знати:
Але для ERP API має бути розумнішим за простий CRUD. ! видалити виступає ключовою рисою * Delete. * створити характеристику;
- переглянути характеристику;
- змінити характеристику;
- видалити або деактивувати характеристику;
- прив’язати характеристику до сутності;
- заповнити значення характеристики;
- змінити значення;
- фільтрувати за характеристиками. Тільки в ERP цей «записник» здатна містити бізнес-середовище на мільйони рядків. Backend відповідає за:
- створити документ;
- переглянути документ;
- редагувати чернетку;
- провести документ;
- скасувати документ;
- видалити чернетку;
- переглянути фінансові поля;
- експортувати;
- друкувати;
- прикріплювати файли. # Захищати файли так само, як записи.== CRUD і ролі доступу ==
Експорт: як приклад:
! # Валідовувати всі вхідні інформаційні дані. ! # Не дозволяти видаляти інформаційні дані, які вже вплинули на обліковий облік. CRUD
У K2 ERP CRUD виступає як основою роботи з бізнес-сутностями: товарами, клієнтами, документами, CRM, файлами, компаніями, характеристиками, ролями та інтеграціями. як приклад:
CRUD і Backup
- прийом запиту;
- перевірку автентифікації;
- перевірку авторизації;
- валідацію даних;
- виконання бізнес-правил;
- роботу з базою даних;
- транзакції;
- обробку помилок;
- логування;
- відповідь API;
- оновлення версій кешу;
- запуск фонових задач. Майже кожна бізнес-система, ERP, CRM, API або база даних має CRUD-операції. Головне. CRUD — це базова модель роботи з даними: створити, прочитати, оновити й видалити. CRUD потрібно тестувати. У CRM CRUD застосовується для для:
K2 ERP як українська ERP-платформа має будувати власну культуру роботи з даними: не хаос у таблицях, а структурований, захищений і керований обліковий облік. Він має перевірити, чи користувач системи має право це робити, чи інформаційні дані правильні й чи операційна дія не зламає бізнес-логіку. ! Оновити. Create — операційна дія створення нового запису або об’єкта.Cache здатна прискорювати CRUD, але потребує обережності.== CRUD і інтеграції ==
Імпорт і експорт часто виступає як розширенням CRUD. ERP потребує CRUD плюс бізнес-логіку, права, валідацію, транзакції, audit log і інтеграції. Без CRUD платформа не здатна нормально працювати з даними. користувач системи відкриває довідник товарів. Деколонізація через інформаційні дані. Українська ERP має давати не лише новий інтерфейс, а й нову культуру CRUD: контрольоване створення, читання, оновлення версій й видалення бізнес-даних.
! Приклади Update:
Приклади:
- зрозумілі сутності;
- контрольовані CRUD-операції;
- права доступу;
- audit log;
- API;
- хмарна робота;
- документи з історією;
- файли в контексті операцій;
- гнучкі характеристики;
- відмова від Excel-хаосу. # Обмежувати права за ролями. У бізнес-системах Delete часто виступає як найризикованішою операцією. # Показувати, що саме буде видалено або архівовано. * провести документ;
- скасувати документ;
- надіслати звіт;
- синхронізувати замовлення;
- сформувати чек;
- закрити період;
- відновити запис. # Для ERP обережно використовувати hard delete. |-
| Які HTTP-методи часто відповідають CRUD? # контролювати імпорт і масові зміни. Для українського бізнесу якісний CRUD — це перехід від хаотичних таблиць і ручних виправлень до керованих даних, прозорих змін і цифрової незалежності. CRUD
Бізнес-логіка питає:
- створення товарів;
- перегляд товарів;
- редагування товарів;
- видалення товарів. CRUD-операції мають бути захищені. Але саме там часто живуть найважливіші помилки доступу й даних. |-
| Чому CRUD важливий для ERP?== CRUD і Code Review ==
Звіти зазвичай належать до Read-операцій, але вони можуть бути складнішими. Звіт здатна:
- статуси документів;
- проведення;
- залишки;
- періоди;
- права;
- історію;
- звіти;
- інтеграції;
- фіскалізацію;
- файли;
- аудит;
- залежні записи. Якщо користувач системи здатна переглянути інформаційні дані, він уже отримав доступ до інформації. як приклад, змінити назву товару — це одне. Це типова модель REST API. як приклад, чек після фіскалізації не можна без зусиль «оновити» або «видалити» як звичайний запис.
CRUD і Import/Export
CRUD — це не вся бізнес-логіка, але це її базовий рівень. # Враховувати multi-tenant ізоляцію.== CRUD і Authorization ==
CRUD і Authentication
CRUD у K2 ERP
Це вже не без зусиль CRUD, а бізнес-операції. * потрібно враховувати такі записи у запитах;
- база здатна накопичувати старі інформаційні дані;
- потрібні правила архівації;
- можуть виникати помилки, якщо забути фільтр активності. У бізнес-системах кожна операційна дія має враховувати права доступу, історію змін, перевірки, зв’язки між даними, документи, звіти, інтеграції та безпеку.== CRUD і Concurrency ==
Bug у CRUD здатна мати різні наслідки. Перегляд даних так само має бути захищений. Літера
- імпорт товарів;
- масове оновлення версій цін;
- масове архівування клієнтів;
- завантаження файлів;
- синхронізація замовлень;
- оновлення версій статусів;
- експорт даних. Якщо її зробити неправильно, вона масово зробить неправильно. * чи виступає як перевірка прав;
- чи виступає як валідація;
- чи правильна транзакція;
- чи виступає як audit log;
- чи не ламаються зв’язки;
- чи правильно функціонує soft delete;
- чи не відкриваються чужі інформаційні дані;
- чи API не повертає зайве;
- чи виступає як тести;
- чи не зламана продуктивність. Transaction або транзакція — механізм, який дає можливість виконати кілька змін як одну цілісну операцію. У програмному забезпеченні CRUD зустрічається всюди:
Зовнішні посилання
ERP-підхід. CRUD у бізнес-системі має бути підпорядкований бізнес-логіці. * `GET /customers`
- `POST /customers`
- `GET /customers/{id}`
- `PATCH /customers/{id}`
- `DELETE /customers/{id}`
SEO title: CRUD — Create, Read, Update, Delete у базах даних, API, ERP та K2 ERP
SEO keywords: CRUD, Create Read Update Delete, створення читання оновлення видалення, база даних, backend, API, frontend, ERP, K2 ERP, CRM, database, REST API, авторизація, автоматизація бізнесу, українське програмне забезпечення
</noinclude>
{{SEO
Шаблон для службового SEO-опису сторінки.
}}
Тому CRUD в ERP — це базова модель, але не повна логіка системи. # Не вважати CRUD «простою частиною», бо саме там часто виникають серйозні баги. * кожен запис має належати певному tenant;
- запити мають фільтруватися за tenant;
- права мають перевіряти tenant;
- cache має враховувати tenant;
- API не має повертати чужі інформаційні дані;
- audit log має зберігати контекст tenant. ERP має розуміти різницю. * стара ціна;
- нова ціна;
- старий статус;
- новий статус;
- хто змінив;
- коли змінив;
- причина зміни;
- коментар. Файли потрібно захищати правами доступу так само, як і записи бази даних. У K2 ERP можливість прикріплювати файли до об’єктів системи важлива для первинки, договорів, рахунків, актів, сканів, фото товарів та інших документів.
Особливістю K2 ERP виступає як можливість розширення сутностей за рахунок характеристик, прикріплення файлів та робота з багатьма підприємствами й компаніями. Тому читання має контролюватися авторизацією. ! !== CRUD і файли == CRUD — це одна з найпростіших і водночас найважливіших моделей у програмуванні. # Давати користувачу зрозумілі підтвердження. Основні правила:
Див. так само
! як приклад, створення документа здатна включати:
Але в реальній ERP операційна дія не обмежується одним SQL-запитом. Потрібні правила, статуси, скасування, службові операції, фіскальні вимоги та історія продукту.== CRUD і Validation ==
як приклад:
Імпорт:
CRUD у багатокористувацькій ERP — це вже не без зусиль кнопки. Правильний підхід. CRUD у бізнес-системі має працювати разом із авторизацією, валідацією, транзакціями, audit log, soft delete, cache invalidation, тестами й бізнес-правилами.
У CRUD-багів часто серйозний вплив, бо вони зачіпають саму роботу з даними.== CRUD і Batch operations == Автентифікація відповідає на питання: хто користувач системи? |- | Як CRUD пов’язаний із K2 ERP? У GraphQL CRUD здатна реалізовуватися через:
Для K2 ERP це критично, бо платформа розрахована на роботу багатьох підприємств і компаній. Масова операційна дія — це CRUD із м’язами. Проста аналогія. CRUD — це як робота з записником: додати контакт, подивитися контакт, змінити номер телефону, видалити старий запис. REST часто використовує CRUD-модель для роботи з ресурсами. |- | Що таке CRUD? В ERP — майже ніколи.== CRUD і транзакції == |- | Create | POST | `POST /products` |- | Read | GET | `GET /products/123` |- | Update | PUT або PATCH | `PATCH /products/123` |- | Delete | DELETE | `DELETE /products/123` |}
CRUD і Bug report
Це здатна бути потрібно для:
- створити товар;
- отримати товар;
- оновити товар;
- видалити товар.== CRUD і Audit log ==
- інтернет-магазин створює замовлення в ERP;
- ERP читає статус оплати;
- зовнішній сервіс оновлює клієнта;
- платформа видаляє або архівує старий токен;
- ПРРО отримує інформаційні дані чека;
- API передає статус документа.== CRUD і цифрова незалежність України ==
CRUD описує чотири найпоширеніші дії з даними. Якщо безпека тримається лише на прихованих кнопках у frontend, це не безпека.== CRUD і Testing ==
Приклади Create:
Для K2 ERP як хмарної ERP це базова частина архітектури. Наслідок
Для інтеграцій CRUD має бути особливо контрольованим, бо зовнішній сервіс здатна масово створювати або оновлювати інформаційні дані. як приклад:
! У базі даних CRUD відповідає основним операціям над таблицями. Validation або валідація — перевірка даних перед CRUD-операцією.== Коротко ==
- компанії;
- користувачі;
- ролі;
- товари;
- клієнти;
- постачальники;
- документи;
- первинка;
- CRM-записи;
- файли;
- звіти;
- характеристики;
- довідники;
- конфігурація;
- інтеграції;
- інтернет-магазини;
- РРО/ПРРО;
- API-токени;
- бізнес-процеси. # Не повертати зайві поля через API.
Delete — операційна дія видалення запису. Але в реальній ERP за кожною з цих дій стоять права доступу, бізнес-правила, історія продукту, транзакції, зв’язки, документи, звіти, файли, інтеграції й відповідальність за інформаційні дані.