```В 100% случаев задачу можно решить без СУБД вообще... но

если с тем же качеством — лет этак через 200. ;)
Т.е. у нас тут в отрасли (вообще в программировании, да) куча средств в принципе эквивалентных по выразительной мощности (полнота по Тьюрингу и т.п.). Поэтому "можно решить" — это не то, что в норме имеет значение.```
Словоблудие. Так и не сказали, чем та же MongoDB хуже при правильном проектировании коллекций той же PGSQL. Я много на самом деле занимался разработкой и для того, и для другого. И не знаю чем хуже MongoDB, кроме как есть ряд случаев когда PGSQL выигрывает в скорости за счёт реляции.
```Понимающего что, извините? В некоторых ситуациях лучше ФП, в других — ООП, скорее всего.
Паттерн. ООП - это то же ФП по сути. Объект - есть так же функция высшего порядка. Со слов А. Кея - при создании ООП и Smalltalk он брал за основу модель акторов, а они всё же ФП в первую очередь.
Всё, что можно сделать в ООП, может быть написано в ФП. Иногда удобнее ООП, иногда ФП. Но это не значит, что ООП лучше. Он проще, чем ФП, тут да. Джуну ФП будет даваться сложнее. В современных задачах ФП/ООП скорее вкусовщина и квалификация команды.
```Это "синдром" не забивания гвоздей микроскопом. ;) Т.е. RDBMS [намного] лучше решают одни задачи, NoSQL — другие.
Я с этим не спорю. Но в большинстве своём - NoSQL и SQL будут решать +/- одинаково по издержкам, отличаться будет схема хранения. И то, может быть на уровне адаптера к БД. В коде бизнес-логики не должно быть слоя данных ведь.
И это, опять-таки, в норме никому не интересно, см. выше.
Популярность PGSQL лишь говорит о низкой квалификации большей части специалистов в NoSQL, не более. Есть задачи где PGSQL будет в разы хуже ArangoDB, верно и обратное. Но это опять же - просто специфика. Самое интересное - фанатики "реляции" пытаются часто есть кактус и всё тащат в неё. А вот инженеры хорошо знающие ещё и NoSQL понимают, что надо отталкиваться от задачи и что реляция очень часто дорого.
Ну из примеров - сделайте полнотекстовый поиск по N полям в PGSQL на товаров более 1 млн в нескольких таблицах. И поймёте почему многие выбирают ElasticSearch тот же.
ну и да. Так, PGSQL хорошо. Но почему-то такие компании как Google продолжают держать хранение многого на MongoDB, а не пихают всё подряд в PGSQL. И большие же компании позволили благодаря вливаниям по фичастости MongoDB уже перегнать PGSQL и стать стандартом в энтерпрайзе для NoSQL.

Лично я очень надеялся чтобы мой вопрос не вызовет холивора, но видимо все таки зацепило, хотя я скорее больше по привычке боялся противостояния ms vs linux. А получилось гораздо глубже sql vs nosql. Я к сожалению с nosql не сталкивался, да и в моей конторе таковых наверное нет. Зато теперь будет для себя интересно глянуть что за зверь такой этот nosql. Наверное надо быть большим спецом и в sql, и в nosql чтобы однозначно сказать вот здесь мы возьмём mongodb, а вот тут pgsql/oracle/mssql/etc Видимо потому и тянут возможно в сторону sql. Потому что знают больше в sql

> Словоблудие. No you. Если Вы этого не понимаете — пишите всё в машинном коде, не стесняйтесь. И да, было бы хорошо, если бы Вы не "отмахивались", а писали по существу. > Паттерн. ООП - это то же ФП по сути. Хмм... вот это бред так бред, извините. ;) Почитали бы Вы определения того и другого, что ли... > Объект - есть так же функция высшего порядка. Ссылку дайте вот на это вот. > Всё, что можно сделать в ООП, может быть написано в ФП. "Потрясающе". Вы бы прочитали, что я Вам писал выше, что ли. > Со слов А. Кея - при создании ООП и Smalltalk он брал за основу модель акторов, а они всё же ФП в первую очередь. Не нужно приплетать сюда Алана — то, что он имел в виду, и то, что сейчас обычно называют ООП, имеют очень мало общего (не верите — сходите почитайте его объяснения / ответы на вопросы вроде "что Алан Кей имел в виду (vs "современное ООП")?"). > В коде бизнес-логики не должно быть слоя данных ведь Кто Вам это сказал? > Популярность PGSQL лишь говорит о низкой квалификации большей части специалистов в NoSQL, не более. Может, это популярность NoSQL говорит о низкой квалификации большей части "специалистов" в моделировании данных вообще и в реляционной модели в частности? ;) > Самое интересное - фанатики "реляции" пытаются часто есть кактус и всё тащат в неё. Потому что "фанатики" с нетерпением ждут, когда же им покажут хоть одну другую математическую модель данных, и подозревают, что NoSQL — это "cнова здорово" набор ad-hoc практик, которые с омерзением выкинули с появлением реляционных СУБД те, кому приходилось тогда есть этот кактус. ;) > что реляция очень часто дорого. Реляция — это всего лишь модель данных, Вы это понимаете? Она не может быть "дорогой" в принципе. > Ну из примеров - сделайте полнотекстовый поиск по N полям в PGSQL на товаров более 1 млн в нескольких таблицах. И поймёте почему многие выбирают ElasticSearch тот же. А что я пойму-то? Что выбравшие ElasticSearch не умеют пользоваться PostgreSQL? ;) Или то, что возможностей PostgreSQL не хватает для каких-то конкретных видов поиска? > Но почему-то такие компании как Google продолжают держать хранение многого на MongoDB, а не пихают всё подряд в PGSQL. Причём тут какие-то "большие компании"? Вы всерьёз считаете вот это вот аргументом... для обоснования хоть чего-то?! > И большие же компании позволили благодаря вливаниям по фичастости MongoDB уже перегнать PGSQL и стать стандартом в энтерпрайзе для NoSQL. Хмм... о чём, вообще, речь?!

> И большие же компании позволили благодаря вливаниям по фичастости MongoDB уже перегнать PGSQL и стать стандартом в энтерпрайзе для NoSQL. Это очень смелое заявление, несколько отличающееся от действительности.

Google использует MongoDB?