@Satangelus

NoSql vs Реляционные СУБД. Как правильно выбрать СУБД, чтобы потом не было мучительно больно?

В рамках проекта выбираю СУБД.В начальной стадии проекта предполагается хранение данных документов, что по идее склоняет чашу весов в пользу NoSQL, но потом появится немножко математики, обороты, остатки и т.д. В дальнем прицеле веб-сервис, который будет синхронизироваться с приложением.

Что лучше выбрать, что потом не было мучительно больно в доработке(разработке)? Реляционные таблицы или NoSql?
а) для декстопа?
б) для сайта?
  • Вопрос задан
  • 306 просмотров
Пригласить эксперта
Ответы на вопрос 4
inoise
@inoise
Solution Architect, AWS Certified, Serverless
Пока у вас нет хайлоада - выбирайте то что знаете лучше. Поверьте, лучше работать с привычным иструментом, чем набивать шишки в новом
Из моих предпочтений:
- Если у вас предполагается структуризация данных и связи то SQL без вариантов
- Если у вас базовые аналитические запросы то SQL, но если данных станет овердофига то посмотрите на NoSQL ColumnBased
- Для кэшированных данных NoSQL Key-Value
- Если у вас микросервисная архитектура то я бы советовал смотреть больше на NoSQL DocumentType
Ответ написан
Комментировать
POS_troi
@POS_troi
СадоМазо Админ, флудер, троль.
данных документов

Вы-же понимаете что это очень размытое понятие? То что в той-же монге оперируют сущностью "документ" это ещё ни очём не говорит для принятия решения в пользу монги :)

В том-же постгресе уже давно завезли JSONb и там можно математику.

Для себя изучал этот вопрос и то-же смотрел в сторону NoSQL БД, у меня данные в которых в принципе много неизвестных типов и их количество (финансовая аналитика), в результате натянул это всё на реляционную модель.
А вот в чём NoSQL сгодилась, так это как кэш аналитических итогов - что-бы не грузить постгрес одними и теми-же запросами.
Ответ написан
@AlexHell
Юзайте SQL базу с которой знакомы, т.е можете конфиг настроить, подтюнить, производительность замерьте и все будет быстро. На счет NoSQL - вообще сомнительная наработка как по мне, все можно в SQL, с prepared statement если на парсинг SQL времени много (только по рез-там тестов).
Ответ написан
Комментировать
@managrib
Разжевано где у кого преимущества:
Postgres vs Mongo / Олег Бартунов
Ответ написан
Комментировать
Ваш ответ на вопрос

Войдите, чтобы написать ответ

Войти через центр авторизации
Похожие вопросы