---
title: "Про великі таблиці Custom Data"
description: "Чому великі реєстри в Custom Data залишаються доступними, як працює безпечний порядок записів і навіщо прискорення сортування потребує явного підтвердження адміністратора."
---

# Про великі таблиці Custom Data

Реєстр заявок за рік, звіт по SKU, історія звернень — у сервісних операціях таблиці ростуть до сотень тисяч і більше рядків. Custom Data розрахований на такий обсяг: команда продовжує працювати з записами, а система захищає стабільність платформи без «закриття» таблиці через повільне сортування.

---

## Чому це важливо

У зовнішніх таблицях або легких сховищах automation-конструкторів великий список часто дає один з двох результатів:

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

У Custom Data інший принцип: **таблиця має залишатися робочим інструментом**, навіть коли обране сортування ще не готове для миттєвого відкриття.

---

## Безпечний порядок замість тупика

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

1. Таблиця **відкривається** — ви бачите сторінку записів, а не помилку.
2. Записи показуються в **безпечному порядку** — зазвичай за ідентифікатором запису (новіші або старіші зверху).
3. Над таблицею з’являється **пояснення**: яке сортування ви обрали і яке застосовано фактично.
4. Ви можете **залишити поточний порядок** і продовжити фільтрувати, редагувати, експортувати записи.

Це не «зламана» таблиця — це свідомий компроміс: **доступність зараз** замість хвилин очікування або недоступності.

---

## Чому прискорення потребує підтвердження

Щоб сортування за потрібним полем (дата, статус, назва) відкривалося швидко на великій таблиці, системі потрібна **службова підготовка** — аналог індексу в базі даних. Ця операція:

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

Тому ConnectiveOne **не робить це автоматично** без відома адміністратора. Замість цього:

1. Система показує **оцінку ризику** — скільки приблизно записів, які поля, чи таблиця велика.
2. Адміністратор **двічі підтверджує** запуск — усвідомлює можливі перебої.
3. Під час підготовки **таблиця залишається доступною** в безпечному порядку.
4. Після успішного завершення обране сортування має працювати швидше.

Детальна інструкція: [Як прискорити сортування на великій таблиці](../how-to/prepare-sort-index-for-large-table.md)

---

## Що це дає команді

| Роль | Що отримує |
|------|------------|
| **Оператор / супервайзер** | Реєстр завжди відкривається; можна працювати з записами, навіть якщо «ідеальне» сортування ще готується |
| **Адміністратор** | Контроль над прискоренням: коли запускати, з яким ризиком, без сюрпризів у пік-годину |
| **Інтегратор** | Один реєстр для процесів і для людей — без окремого «технічного» шару для великих обсягів |

---

## Чим це відрізняється від інших підходів

- **Google Sheets / Excel** — зручно редагувати, але великий лист гальмує; немає вбудованого механізму «безпечного відкриття» з поясненням.
- **Таблиці в automation-конструкторах** — часто без UI для щоденної роботи команди на великих обсягах.
- **Окремий admin-портал** — потрібна окрема оптимізація і підтримка.

Custom Data поєднує **UI для команди**, **дані для процесів** і **захист від перевантаження** в одному модулі. Порівняння з іншими підходами — [Чим Custom Data сильніша](./custom-data-vs-other-approaches.md).

---

## Пов'язані матеріали

- [Як прискорити сортування на великій таблиці](../how-to/prepare-sort-index-for-large-table.md)
- [Як сортувати записи](../how-to/sort-records.md)
- [Як переглянути записи таблиці](../how-to/view-model-records.md)
- [Admin Hub](../admin-hub.md)