SQL проти NoSQL: яка база даних потрібна вашому застосунку?

SQL-бази (їх також називають реляційними) зберігають дані в таблицях із визначеною структурою — рядках і стовпцях — і пов'язують пов'язані таблиці між собою. Запити до них пишуться мовою SQL. Прикладами є Postgres, MySQL і SQLite. NoSQL-бази використовують інші способи зберігання даних — документи, пари ключ-значення, широкі стовпці або графи — і зазвичай дозволяють гнучкішу структуру. Прикладами є MongoDB, Redis, DynamoDB і Firestore. Для більшості бізнес-застосунків SQL-база — розумний вибір за замовчуванням; NoSQL найкраще показує себе у певних завданнях.

Чому цей вибір важливий, коли ви створюєте застосунок з AI

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

Коли AI-конструктор застосунків додає для вас зберігання даних, він обирає один із цих варіантів. Знання різниці допомагає вам:

• Зрозуміти, як виглядають ваші дані і чи можуть вони відповісти на питання, які ви поставите пізніше («виручка за місяць за продуктом»).
• Оцінювати вибір платформи. Деякі платформи побудовані на документній базі, інші — на реляційній. Дивіться Supabase проти Firebase як типовий приклад кожного з них.
• Уникнути прив'язки до постачальника. SQL — спільний стандарт, тож реляційні дані зазвичай легше перенести між провайдерами.

Проста аналогія

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

NoSQL-документна база схожа на картотеку з папками. У папці кожного клієнта можуть разом зберігатися його дані та замовлення, і одна папка може містити додаткові документи, яких немає в інших. Отримати всю історію одного клієнта швидко. А відповідь на питання «що всі замовили минулого місяця?» означає відкриття багатьох папок.

Справжні відмінності

«NoSQL» — це не одна річ. Основні види:

Приклад: ті самі дані магазину, два способи

Візьмемо невеликий онлайн-магазин із клієнткою та її замовленнями.

SQL (реляційна): дані розділено на таблиці та пов'язано через ID.

-- customers: id=1, name='Lena Ortiz'
-- orders:    id=101, customer_id=1, total=42.00
--            id=103, customer_id=1, total=25.00

SELECT c.name, SUM(o.total)
FROM customers c JOIN orders o ON o.customer_id = c.id
GROUP BY c.name;

Якщо Лена змінить свою електронну пошту, це зміниться в одному місці. Запит «сума продажів на клієнта цього місяця» — це один запит.

NoSQL (документ): її замовлення можуть жити всередині її документа.

{
  "_id": "cust_1",
  "name": "Lena Ortiz",
  "email": "lena@example.com",
  "orders": [
    { "id": 101, "total": 42.00, "items": ["Green tea"] },
    { "id": 103, "total": 25.00, "items": ["Teapot"] }
  ]
}

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

Жоден варіант не є неправильним. Питання в тому, який шаблон найчастіше використовує ваш застосунок.

Як обрати

Реляційна SQL-база зазвичай є правильним вибором за замовчуванням, якщо:

• У ваших даних багато зв'язків: користувачі, команди, бронювання, рахунки, товари.
• Вам потрібні звіти, фільтри й підсумки по записах.
• Важлива коректність: гроші, залишки на складі, дозволи.

NoSQL-базу варто розглянути, якщо:

• Вам потрібне швидке сховище кешу або сесій — тут часто використовують Redis, зазвичай разом із SQL-базою.
• Ваших записів дуже багато, вони прості й незалежні, як журнали подій або показники датчиків.
• Ви працюєте на платформі, побудованій навколо такої бази, як Firestore від Firebase, і її функції реального часу — головна причина вибору.

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

Ключові терміни

Поширені хибні уявлення

• «NoSQL означає відсутність схеми». Ваші дані завжди мають певну форму. У NoSQL база може не перевіряти її, тому це має робити ваш код.
• «SQL не масштабується». Реляційні бази обслуговують дуже великі сервіси. Більшість застосунків ніколи не наближаються до своїх меж.
• «NoSQL завжди швидший». Лише для тих шаблонів, на які він розрахований. Наскрізний звіт може бути повільнішим.
• «Треба вибрати один назавжди». Багато застосунків поєднують обидва варіанти. А SQL-бази на кшталт Postgres також зберігають JSON, тож кілька гнучких полів не вимагають NoSQL.
• «NoSQL означає, що не можна використовувати SQL». Назву зазвичай читають як «не лише SQL», а деякі NoSQL-продукти пропонують мови запитів, схожі на SQL.

Про що запитати ваш AI-конструктор

• «Який тип бази даних використовує цей застосунок і чому він підходить для моїх даних?»
• «Намалюй таблиці або колекції та те, як вони пов'язані.»
• «Які звіти мені знадобляться через півроку? Чи зможе ця база легко їх побудувати?»
• «Якщо кілька полів справді гнучкі, зберігай їх як JSON у Postgres, а не додавай другу базу.»
• «Додавай кеш лише тоді, коли буде виміряна проблема швидкості.»

Бази даних у Mythex

Mythex надає кожному проєкту, якому вона потрібна, окрему базу Postgres — реляційну SQL-базу, яка додається, коли застосунок її потребує, або запитом у чаті, або командою /database (Database). Це підходить для більшості бізнес-застосунків: користувачі, бронювання, замовлення та звіти. Якщо вам потрібна конкретна зовнішня служба, наприклад хостингова документна база, агент може написати код, який підключиться до неї через ключі, збережені як секрети проєкту. Щоб дізнатися більше про саму мову, прочитайте що таке SQL.

Запитання