Що таке база даних? Посібник для тих, хто створює застосунки
База даних — це впорядковане сховище інформації, у яке застосунок записує дані і з якого їх читає: його користувачі, замовлення, бронювання, повідомлення. На відміну від інформації, яка зберігається лише у вкладці браузера, дані в базі даних лишаються після оновлення сторінки чи перезапуску, і всі, хто користується застосунком, бачать одні й ті самі записи. Більшість баз даних організовують дані в таблиці, схожі на аркуші електронної таблиці, але з суворими правилами, які тримають дані узгодженими.
Чому це важливо, коли ви створюєте з ШІ
Найпоширеніший сюрприз для тих, хто створює з ШІ, — застосунок, який виглядає готовим, але все забуває. Ви додаєте клієнта, оновлюєте сторінку — і його немає. Зазвичай це означає, що застосунок зберігав дані в пам'яті браузера, а не в базі даних.
База даних також є місцем, де живуть багато ваших найважливіших рішень, знаєте ви про це чи ні:
- Що ви записуєте. Якщо не зберігати статус бронювання, неможливо показати, які бронювання скасовано.
- Як речі пов'язані. Чи може один клієнт мати багато бронювань, а одне бронювання — багато послуг, — це формує весь застосунок.
- Хто що бачить. Більшість помилок у приватності стосуються того, які записи може читати користувач.
Вам не потрібно самим проєктувати базу даних. Але розуміння основ дозволяє чітко описати свої дані і вчасно помітити проблеми.
Побутова аналогія
Уявіть добре організовану картотеку в невеликому офісі.
Кожна шухляда містить один вид речей: одна — для клієнтів, інша — для прийомів, третя — для рахунків. Усередині кожної шухляди кожна папка має однаковий формат із тими самими заповненими полями. У кожної папки є унікальний номер, а якщо рахунок належить клієнту, у папці рахунку записаний номер клієнта, а не скопійований весь його файл.
Це і є реляційна база даних. Шухляди — це таблиці, папки — рядки, поля — стовпці, номери — первинні ключі, а записи, що вказують на іншу папку, — зовнішні ключі. Хороший офіс-менеджер також дотримується правил: без прийому без дати, без двох клієнтів з однаковим номером — так само, як і база даних.
Практичний приклад: застосунок для запису в салон краси
Скажімо, ви просите ШІ створити сайт для запису в перукарню. Розумна база даних матиме чотири таблиці.
services
| id | name | duration_minutes | price |
|---|---|---|---|
| 1 | Стрижка | 45 | 40.00 |
| 2 | Фарбування | 90 | 95.00 |
staff
| id | name | |
|---|---|---|
| 1 | Сара | sara@example.com |
| 2 | Омар | omar@example.com |
customers
| id | name | phone | |
|---|---|---|---|
| 101 | Лена Парк | lena@example.com | 555-0100 |
bookings
| id | customer_id | service_id | staff_id | starts_at | status |
|---|---|---|---|---|---|
| 5001 | 101 | 1 | 2 | 2026-10-03 14:00 | confirmed |
Подивіться на таблицю bookings. Вона не копіює ім'я та номер телефону Лени в кожне бронювання; вона зберігає customer_id = 101. Якщо Лена змінить номер телефону, він зміниться в одному місці, і кожне бронювання покаже новий. Це основна ідея реляційної бази даних: зберігати кожен факт один раз і посилатися на нього.
Та сама структура відповідає на корисні запитання:
- «Які години вільні у Омара в п'ятницю?» — переглянути бронювання Омара на цей день.
- «Скільки заробили фарбування цього місяця?» — з'єднати бронювання з послугами і підсумувати ціни.
- «Які клієнти не записувалися понад 90 днів?» — порівняти клієнтів з їхнім останнім бронюванням.
Поширені терміни
| Термін | Що означає |
|---|---|
| Таблиця | Колекція записів одного виду, як-от клієнти або бронювання. |
| Рядок (запис) | Один елемент таблиці — один клієнт, одне бронювання. |
| Стовпець (поле) | Одна частина інформації, яка є в кожному рядку, як-от email або ціна. |
| Первинний ключ | Унікальний ID кожного рядка, зазвичай число або випадковий рядок. |
| Зовнішній ключ | Стовпець, що вказує на рядок в іншій таблиці, як-от customer_id у bookings. |
| Схема | Загальний задум: які таблиці існують, їхні стовпці та як вони пов'язані. |
| Запит | Запит на читання або зміну даних, наприклад «усі бронювання на завтра». |
| SQL | Structured Query Language, стандартна мова запитів для реляційних баз даних. |
| Міграція | Збережена, повторювана зміна схеми, наприклад додавання стовпця. |
| Індекс | Структура пошуку, яка прискорює пошук за стовпцем, як предметний покажчик у книжці. |
| CRUD | Create, Read, Update, Delete — чотири базові дії застосунків з даними. |
| Резервна копія | Копія даних, яку можна відновити, якщо щось піде не так. |
Типи баз даних
| Тип | Як зберігає дані | Приклади | Добре підходить для |
|---|---|---|---|
| Реляційна (SQL) | Таблиці з фіксованими стовпцями та зв'язками між ними | Postgres, MySQL, SQLite | Більшість бізнес-застосунків: записи, магазини, CRM, SaaS |
| Документна (NoSQL) | Гнучкі документи, схожі на JSON | MongoDB, Firestore | Дані, структура яких сильно відрізняється від запису до запису |
| Ключ-значення | Значення, збережене під ключем | Redis | Кешування, короткочасні дані на кшталт сесій |
Для майже всього, що засновник або малий бізнес створює першим, реляційна база даних — безпечний вибір за замовчуванням.
Де база даних у вашому застосунку
Відвідувачі ніколи не звертаються до бази даних напряму. Сторінка в їхньому браузері (фронтенд) просить ваш сервер (бекенд) про дані, зазвичай через API. Сервер перевіряє, хто питає і чи має він на це право, потім робить запит до бази даних і надсилає назад лише те, що цій людині можна бачити.
Цей проміжний крок важливий. Якби браузер міг напряму запитувати базу даних з повним доступом, будь-хто міг би відкрити інструменти розробника і прочитати все.
Типові помилки та хибні уявлення
- Зберігання даних лише в браузері. Браузерне сховище (наприклад, localStorage) живе на одному пристрої і в одному браузері. Воно годиться для запам'ятованого фільтра, але не для замовлень.
- Усе в одній таблиці. Єдина таблиця «бронювань», де ім'я клієнта, телефон і ціна послуги скопійовані в кожен рядок, швидко розсинхронізується.
- Зберігання паролів у відкритому вигляді. Паролі мають хешуватися, а не зберігатися читабельними. Див. що таке автентифікація.
- Немає правил для даних. Без обов'язкових полів і правил унікальності ви отримаєте бронювання без дати і дублікати клієнтів.
- Забули про видалення. Вирішіть, чи видалення клієнта видаляє його бронювання, зберігає їх чи блокується.
- Експерименти на реальних даних. Ризиковані зміни спершу перевіряйте в безпечному місці і тримайте резервні копії.
- Вважати електронну таблицю базою даних назавжди. Таблиці чудові на старті, але погано справляються з багатьма одночасними користувачами і правами доступу. Див. як перетворити електронну таблицю на застосунок.
Що запитати у вашого конструктора на основі ШІ
- «Збережи це в базі даних, а не в браузері. Скажи, які таблиці ти створиш».
- «Покажи схему у вигляді простої таблиці: кожна таблиця, її стовпці і як вони пов'язані».
- «Клієнт може мати багато бронювань; кожне бронювання має рівно одну послугу і одного працівника».
- «Зроби email обов'язковим і унікальним для клієнтів».
- «Не дозволяй, щоб два бронювання для одного працівника перетиналися».
- «Лише авторизований власник може читати всі бронювання; клієнти бачать лише свої. Забезпеч це на сервері».
- «Коли я видаляю послугу, не видаляй минулі бронювання — лише познач послугу як неактивну».
Бази даних у Mythex
Коли вашому застосунку потрібно зберігати дані, Mythex додає до проєкту окрему базу Postgres — ви можете попросити в чаті («зберігай реєстрації в список очікування в базі даних») або скористатися командою /database. Параметри підключення автоматично передаються вашому застосунку, а агент створює таблиці. База засинає після п'яти хвилин бездіяльності і прокидається на наступний запит, а для опублікованих застосунків плата нараховується за час, коли база була активна, з того самого балансу кредитів, що й для створення. Вона доступна на тарифах Free і Pro. Деталі — у документації про бази даних, а шаблони застосунків містять стартові варіанти з роботою з даними.
Запитання
Що таке база даних простими словами?
База даних — це впорядковане сховище інформації, у яке застосунок може записувати дані і з якого їх читати, наприклад користувачів, замовлення чи записи. На відміну від даних, що зберігаються лише у вкладці браузера, вони лишаються після оновлення сторінки, перезапуску або коли хтось відкриває застосунок з іншого пристрою.
Чи є електронна таблиця базою даних?
Електронна таблиця може зберігати такі самі дані, але вона не створена для застосунків. Справжня база даних стежить за правилами щодо того, що містить кожен стовпець, надійно пов'язує таблиці, обробляє запис від багатьох людей одночасно і контролює, хто що може читати.
У чому різниця між SQL і NoSQL базами даних?
SQL (реляційні) бази даних, як-от Postgres і MySQL, зберігають дані у таблицях з визначеними стовпцями та зв'язками між ними. NoSQL бази даних, як-от MongoDB, зберігають гнучкіші документи. Більшість бізнес-застосунків — записи, CRM, магазини — добре лягають на реляційну модель.
Чи потрібна моєму застосунку база даних?
Так, якщо він має запам'ятовувати те, що вводять люди, — реєстрації, замовлення, повідомлення, налаштування — і показувати це пізніше або іншим людям. Суто інформаційний сайт без форм, які щось зберігають, зазвичай не потребує бази даних.