Привіт друзі - ну що чучуть розберемо цей пул?


(A) Excel ну я думаю тут не будемо сильно зупиняться і так все понятноТак,
Excel топ для таблиця хто що здав, але JSON з вкладеним масивом у Excel виглядає як трагедія.
Пробуєте розтягнути items, зберегти цілісність структури, а потім ще це все парсити... Це не база це костиль)


Чому все ж не (B) хоча так хотілось би, Так?
На перший погляд виглядає як норм: робимо таблицю users, окремо items, через user_id зв'язуємо. Але постійно є це АЛЕ, Структура JSON вимагає нормалізації а масив items це взагалі окрема таблиця ну і потрібні JOIN'и для відновлення повної структури
І якщо у product завтра додасться поле price треба міняти схему.

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

(D) Google Docs, для копіпасту - тут теж все просто і зрозуміло)
Ніяких індексів, запитів, цілісності, Це не база, а текстовий документ. JSON там зберігається просто як текст.



ну і чому саме (C) NoSQL, правильна відповідь)
Наприклад, MongoDB, документна база, яка приймає JSON/BSON як є. Це прямо такий об’єкт, без трансформацій, зберігається як документ. Масиви, вкладення, різні типи ну і усе зберігається без втрати структури. це дуже підходить для API-first підходу, де UI/API головні, а база лише бекенд.

Якщо прям Технічно - insertOne({ user: "Іван", items: [...] }), це вже вся операція, як що пошук: db.orders.find({ "items.product": "Чай" }) так кажучи Без JOIN, без схеми, без болю

У тестах зручно перевіряти, що API повертає, і зберігати аналогічну структуру.

як кажуть QA не тільки клік і подивився.
А треба зрозуміти, як і де зберігаються дані, це вже рівень вище.
Бо коли API скаже "500", ти маєш знати, де воно могло впасти.

Обійняв 🤗