Коли вашому застосунку, створеному ШІ, справді потрібна повноцінна база даних (а коли — ні)

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

Що насправді робить база даних?

Уся робота бази даних зводиться до того, щоб двоє людей випадково не перезаписали чи не знищили роботу одне одного, працюючи в одному застосунку водночас — швидкість, структура та складний пошук є лише побічними ефектами розв’язання цієї єдиної проблеми.

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

А потім трапляється одне з двох:

  1. Ваш застосунок стає повільнішим з кожним використанням.
  2. Двоє користувачів намагаються скористатися ним одночасно — і щось ламається.

Жоден з цих збоїв не очевидний, доки не стане запізно. Обидва — це проблеми бази даних, замасковані під щось інше.

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

Коли нормально просто використовувати файли замість бази даних?

Файли чудово працюють, доки ви єдиний користувач застосунку і зміни вносяться рідко — це і є весь тест.

Сайт-портфоліо фрилансера? Файли — ідеальний варіант. Особистий трекер витрат? Файли цілком підходять. Хобі-проєкт з одним користувачем? Не ускладнюйте.

Реальні сигнали, що файли справляються:

  • Застосунком одночасно користується лише одна людина (або користувачі не в мережі, поки працюють інші).
  • Ви оновлюєте дані рідко (раз на день, раз на тиждень, раз на місяць).
  • Втрата останніх 30 секунд роботи прийнятна (ваш білдер може просто спробувати ще раз).
  • Файл з даними достатньо малий, щоб надіслати його електронною поштою (менш ніж 10 МБ).

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

Чому мій застосунок, створений ШІ, стає повільнішим?

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

Ви помічаєте це як відчуття. Застосунок здається повільнішим, ніж раніше. Натискання кнопки займає на секунду більше. Пошук помітно повільніший. Ви не змінювали код — чому ж стало повільніше? Ось як це відбувається:

  1. Застосунок завантажує повний файл даних (100 рядків, швидко).
  2. Користувач додає запис (тепер 101 рядок).
  3. Застосунок повторно зчитує весь файл, щоб перевірити (усе ще швидко).
  4. Після 2000 записів зчитування файлу займає 2 секунди.
  5. Після 10 000 записів — уже 20 секунд.

Це не експоненційне зростання, але воно стає помітним приблизно на 5000 записах і болючим — приблизно на 20 000.

Перше рішення (перед тим, як додавати базу даних): попросіть свого білдера завантажувати дані за потреби. Завантажуйте лише ті записи, які відображаєте, або лише ті стовпці, які показуєте. Багато застосунків можуть залишатися на файлах, якщо розумніше підходити до того, що саме завантажується.

Коли переходити на базу даних: у вас понад 50 000 записів даних, або сповільнення зберігається навіть після оптимізації завантаження.

Чому мій застосунок втратив дані, коли двоє людей використовували його одночасно?

Це трапляється тому, що двоє людей можуть редагувати один і той самий файл одночасно, а застосунок не має способу про це дізнатися — виграє той, хто зберігає зміни другим, а зміни першої людини безслідно зникають. Це називається “конфліктним записом”, і це класична помилка, що призводить до втрати даних.

Обидва бачать свої зміни на екрані. Обидва натискають “зберегти”. Ви зрозумієте, що це відбувається, якщо:

  • Користувачі час від часу повідомляють про зникнення даних (особливо якщо в застосунку одночасно перебувають кілька людей).
  • Користувачі повідомляють, що чужі зміни “скасувалися” без жодних пояснень.
  • Двоє користувачів редагують один і той самий запис, і правки одного з них зникають.
  • Ви отримуєте повідомлення на кшталт “Я точно додавав це вчора, а тепер воно зникло”.

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

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

Чому мій застосунок не може виконувати складні пошукові запити з файлами?

Тому що з файлами вашому білдеру доводиться завантажувати й фільтрувати кожен пов’язаний набір даних вручну, крок за кроком, замість того щоб поставити одне запитання і отримати одну відповідь — база даних виконує ту саму роботу за мілісекунди одним запитом.

Скажімо, ви хочете знайти “усі неоплачені рахунки для клієнтів з Каліфорнії, з якими не було контакту за останній тиждень”. З файлами вашому білдеру доведеться:

  1. Завантажити всі рахунки.
  2. Відфільтрувати ті, де unpaid = true.
  3. Завантажити всіх клієнтів і зіставити за ID.
  4. Відфільтрувати за state = “CA”.
  5. Завантажити всі записи контактів і зіставити за ID клієнта.
  6. Відфільтрувати за date > тиждень тому.

З базою даних ви пишете один запит, і він робить усе це за мілісекунди.

Коли переходити на базу даних: коли ваш білдер каже “щоб відповісти на це питання, знадобиться писати окремий код”. Або коли ви помічаєте, що застосунок виконує дуже багато роботи, щоб просто показати вам відфільтровані дані.

Що сказати своєму білдеру, коли мені потрібна база даних?

Прямо поясніть, що йде не так, і попросіть план дій — щось на кшталт: “Застосунок [сповільнюється / втрачав дані / потребує складніших пошукових запитів]. Думаю, нам варто додати базу даних. Наскільки масштабна це зміна?”

Більшість білдерів можуть перевести застосунок з файлів на базу даних за 1–2 дні для невеликих застосунків, за кілька днів — для більших. Процес такий:

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

Білдер може запитати:

  • “Використовувати PostgreSQL, MySQL чи щось інше?”
    • Ваша відповідь: “Що вам зручніше. Я не знаю різниці, але довіряю вашому вибору.”
  • “Це займе 3 дні. Воно того варте?”
    • Ваша відповідь: “Якщо переходити все одно доведеться, краще раніше, ніж пізніше — поки даних менше.”
  • “Переносити старі дані?”
    • Ваша відповідь: “Так, якщо тільки їх не менше 100 записів — тоді можна почати з чистого аркуша.”

Чи потрібно мені самому розбиратися в базах даних?

Ні — вам не потрібно знати, що таке база даних, вивчати SQL чи зважувати PostgreSQL проти MySQL. Усе, що потрібно сказати білдеру: “Двоє людей повинні мати змогу користуватися застосунком одночасно, не втрачаючи роботу одне одного.”

Оце й усе. Ваш білдер сам обере базу даних. Проста, як-от SQLite (для особистого чи командного застосунку з менш ніж 10 одночасними користувачами), або PostgreSQL (для чогось більшого) — обидва впораються з цим завданням.


Як зрозуміти, чи потрібна моєму застосунку база даних?

Позначте, які з цих чотирьох пунктів стосуються вас — дві або більше позначки означають, що базу даних варто додати вже зараз.

  • Сповільнення: застосунок 3 місяці тому здавався швидшим, а зараз — повільнішим. Файл даних понад 20 МБ або містить понад 10 000 записів.
  • Втрата даних: чиїсь зміни зникли, або кілька користувачів повідомили про втрачені правки.
  • Складність: ви хочете ставити запитання на кшталт “покажи мені X, відфільтроване за Y”, а білдер каже “з файлами це зробити складно”.
  • Користувачі: застосунком одночасно користується більш ніж одна людина (навіть зрідка).

Якщо ви позначили дві або більше позначки, ваш застосунок готовий до бази даних.

Якщо ви не позначили жодної, ваші файли справляються добре. Залишайте як є. Простота — це цінність.

Якщо ви позначили одну позначку, запитайте свого білдера: “Чи достатньо це швидко, щоб протриматися ще 6 місяців?” Якщо так — почекайте. Якщо ні — переходьте зараз.