Зазвичай це одне з найбільш дискусійних питань на старті будь-якого проєкту. Звісно, усе залежить від бізнесу, але давайте трохи узагальнимо й візьмемо середню картину. Для недосвідченого розробника на перший погляд NoSQL-бази даних часто здаються кращим вибором, адже вони виглядають зручнішими з точки зору гнучкості даних і зв’язків між ними.
На практиці все інакше. І навіть якщо спочатку здається, що зв’язків мало, з часом вони точно почнуть з’являтися, а ваші дані можуть перетворитися на хаос.
Один із яскравих прикладів - це зв’язка
Serverless і DynamoDB. Буквально кілька років тому її активно просували майже в усі проєкти, аргументуючи це тим, що так дешевше. Насправді ж DynamoDB вимагає від розробників розуміння доволі складних концепцій, як-от Adjacency List чи Materialized Graph, з якими ніхто не хотів розбиратися 🗿🗿🗿Тому такі проєкти часто трималися на різних костилях, а з часом їх поступово мігрували в умовний PostgreSQL або обкладали додатковими рішеннями для реалізації складних вибірок даних. Один із найпоширеніших варіантів - DynamoDB для запису + реплікація в Elasticsearch для вибірки.
У цілому NoSQL - це круте рішення, коли ви вже добре знаєте модель даних і у вас виникає потреба оптимізувати певні частини системи. Тоді має сенс мігрувати частину даних із реляційної моделі, щоб вирішити конкретний bottleneck.
Але починати проєкт зазвичай найзручніше з SQL, тому що це:
- чітка схема;
- зручні міграції даних;
- менше сміття в даних;
- цілісність даних.