Конечно можно. Можно даже sqlite. Можно даже сериализацию каждой записи в отдельный файл. Можно? Можно.

Нормальные транзакции, эффективные агрегации и выборку данных из кучи таблиц, мощные инструменты поддержки целостности данных, сюда же материализованные представления, представления, ХП.

Если брать Postgres, то при этом в нём будет и возможность хранить документы, и иметь наследование таблиц

Только всё это хорошо работает только пока нет шардирования, репликации и объёмы данных небольшие. С увеличением объёма данных всё равно пользователи реляционных СУБД приходят к денормализации данных. И такие вещи как целостность, сложная агрегация становятся менее актуальными

В этом плане MongoDB сразу предлагает использовать подход с денормализацией данных, так чтобы за один запрос в одной коллекции вытаскивать сразу всё что нужно.

Таким образом если в конечном итоге (в проде с большим объёмом данных) традиционный подход к использованию реляционных СУБД не работает, то зачем это выставлять как плюс.

Я в проектированнии БД в mongodb исхожу из тех соображений, чтобы увеличение объёма данных не снижало скорость получения нужных данных (и mongodb своей архитектурой этому способствует).

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

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

Ты указываешь на проблемы некоторых бесплатных систем. Это не бросает тень на все реляционные БД в принципе. То, что кто-то не доделал в отдельном продукте, не является проблемой всей технологии в целом.

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

> по своей природе
Можно поподробнее на чем основано это утверждение и откуда инфа?

ну, само понятие денормализации БД уже доказательно.

Какие нужны пруфы? Если ставив внешние ключи, либо ограничения на значения полей, значит при каждом добавлении или изменении данных происходят разные проверки на уровне СУБД.
Но их можно и не делать, а делать их например только на уровне архитектуры приложения или вообще не использовать, если это не критично.

На счёт дублирования тоже очевидно же. Допустим есть две таблицы, из них можем через агрегацию достать данные. А можно также сделать одну таблицу, где данные хранить в агрегированном виде и доставать данные оттуда. Тогда будет дублирование, но будет быстрее доступ к данынм

Доказательство чего? Денормализованности? Прошу ознакомиться для начала с матчастью

> Обычно под этим термином понимают стратегию, применимую к уже нормализованной базе данных с целью повышения ее производительности

первая ссылка: https://habr.com/ru/company/latera/blog/281262/

Ну блииин! Ну хоть читайте что скидываете: "Логика в том, чтобы снизить время исполнения определенных запросов через упрощение доступа к данным".

Если честно, я противоречий не нашел. Денормализация? Ага, она самая. Все потому, что производительность.

в монгоДБ можно сделать что-нибудь типа такого: select * from users where balance >= 500 ?

Ликбез и матчасть: Есть всего два пути в стратегии повышения производительности на низком уровне. Это либо быстрая запись, либо быстрое чтение.

Быстрая запись ведётся быстро только при условии последовательной записи блоков.

Быстрое чтение при том же условии.

Но в БД есть одна особенность - это выборка

Выборка ускоряется только при условии ключей заранее отсортированных и опять же последовательном чтении/записи сразу нужной информации.

ПРимер твиттер: разработка изначально велась как раз на РСУБД

Но позже стало ясно, что если к примеру есть суперзвезда с посетителями, то сервер ложился.