Yaroslav Schekin
> В 90% случаях задачу можно решить как через SQL, так и через NoSQL.
В 100% случаев задачу можно решить без СУБД вообще... но если с тем же качеством — лет этак через 200. ;)
Т.е. у нас тут в отрасли (вообще в программировании, да) куча средств в принципе эквивалентных по выразительной мощности (полнота по Тьюрингу и т.п.). Поэтому "можно решить" — это не то, что в норме имеет значение.
> Это как спорить что лучше ФП или ООП, для понимающего человека - те же яйца, только в профиль будут.
Понимающего что, извините? В некоторых ситуациях лучше ФП, в других — ООП, скорее всего.
> Ну и синдром утёнка.
Это "синдром" не забивания гвоздей микроскопом. ;) Т.е. RDBMS [намного] лучше решают одни задачи, NoSQL — другие.
> что покрыть может почти любая БД, такая как Arango покрыть может люблую задачу
И это, опять-таки, в норме никому не интересно, см. выше.
```В 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.
