Аудит моделі даних

Створюйте індекси необхідні для оптимальної продуктивності запитів критеріїв пошуку. При цьому слідкувати за тим щоб не створювалися дублікати або зайві індекси.

Належне індексування є важливим у реляційних базах даних для покращення продуктивності запитів. Без індексів система управління базами даних (СУБД) мусить сканувати всю таблицю, що може бути дуже повільним для великих наборів даних.

Головними кандидатами на індексування є стовпці по яких відбувається пошук та стовпці по яких відбувається з’єднання таблиць у запитах.

Створення індексів може значно покращити продуктивність запитів, але є ситуації, коли варто утриматися від створення індексу або ретельно розглянути, чи варто його створювати:

Використовуйте атрибут indexing="true" тегу ext:createSearchCondition для автоматичного створення необхідних індексів на стовпці по яких відбувається пошук.

Використовуйте тег createIndex для ручного створення індексів, наприклад для ключів по яких відбувається join.

Звертайте увагу на те що система автоматично створює індекси для первинних ключів, унікальних ключів та стовпців пошуку, якщо ввімкнено indexing="true" тегу ext:createSearchCondition, та не створюйте індексів які їх дублюють.

Своєчасно видаляйте дублікати та зайві індекси за допомогою тегу dropIndex.

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

Користуйтесь можливістю виділяти зміни в моделі даних, які були створені в процесі розробки релізу. Наприклад якщо ви створили таблицю і потім вирішили до неї додати колонку не створюйте новий чендж сет addColumn, а перестворіть таблицю з новою колонкою. Так само якщо ви створили критерій пошуку, а потім вирішили його змінити або видалити, просто змініть або видаліть оригінальний чендж сет. Такі операції можуть потребувати очищення розробницького оточення за допомогою clean-up.

Додержуйтесь єдиної конвенції в найменуваннях ідентифікаторів чендж сетів.

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

Встановіть конвенцію для найменування та послідовно дотримуйтеся її протягом усього проєкту. Це забезпечить розуміння всім членам команди правил найменування та легкої ідентифікації змінних.

Використовуйте описові назви, які пояснюють призначення або характер змін. Добре обрана назва повинна чітко розкривати суть зміни.

Додавати в критерії пошуку тільки ті колонки, що використовуються в бізнес-процесі, формах чи зовнішньому АПІ. Якщо колонка не використовується в пошуку, то вона не повинна бути включена в критерії пошуку.

Завжди вказуйте ліміт при моделюванні критеріїв пошуку

Якщо зовнішній сервіс чи бізнес-процес не вкаже ліміт при визові критерію пошуку, та на самому критерії ліміт не вказано, це може призвести як до витоку даних, так і до проблем з продуктивністю системи.

Вказуйте ліміт для критерію пошуку, користуючись атрибутом limit тегу ext:createSearchCondition

Моделюйте схему бази даних в третій нормальній формі.

Третя нормальна форма (3NF) усуває або значно зменшує повторення даних. Це мінімізує ризик невідповідності та аномалій в даних, які можуть виникнути, коли однакові дані зберігаються в кількох місцях. Вона сприяє існуванню єдиного джерела правди для кожного фрагмента даних.

Шляхом усунення повторення даних та забезпечення логічного та організованого зберігання кожного фрагмента даних, 3NF підвищує цілісність даних. Дані залишаються точними та надійними, зменшуючи ризик помилок.

Також завдяки уникненню повторення даних, схеми 3NF зазвичай потребують менше простору для зберігання. Це важливо для економії витрат та ефективного використання ресурсів, особливо в великих базах даних.

Використовувати 3-ю нормальну форму (3NF) як базову для моделювання схеми.

В випадках коли відступ від 3NF є обґрунтованим, наприклад для оптимізації продуктивності, треба глибоко розуміти та враховувати компроміси які виникають.

При необхідності оновлення сутності в бізнес-процесі надавати перевагу частковому оновленню (partial update) замість стандартного повного оновлення сутності.

Створюйте API для часткового оновлення за допомогою тегу ext:partialUpdate та використовуйте при необхідності оновлювати частину стовпців сутності.

Використовуйте стандартні теги Liquibase що надаються платформою.

SQL-вирази, написані в чендж сетах, можуть виявитися не сумісними з новими версіями платформи.

Liquibase забезпечує перевірку та виявлення помилок для стандартних тегів. На відміну від цього, SQL-вирази в чендж сетах не перевіряються Liquibase, і помилки можуть бути виявлені лише під час виконання.

Використовуйте стандартні теги Liquibase що підтримуються платформою.

Якщо з’являється необхідність використати SQL, обов’язково ретельно тестуйте та перевіряйте ваші чендж сети, щоб переконатися, що вони працюють правильно і не вводять помилок у схему бази даних.

Використовуйте можливості пагінації при моделюванні критеріїв пошуку

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

Надання посторінкових результатів дозволяє користувачам переглядати дані у керованих частинах.

Менші за об’ємом результати обробляються швидше, що зменшує навантаження на сервер бази даних.

Обирайте необхідний тип пагінації за допомогою атрибуту pagination тегу ext:createSearchCondition.