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

Большинство реальных разработчиков используют лишь одну СУБД. Да, есть проекты где тестовой используется ещё H2, вспомогательная Non-SQL. Разводить зоопарк очень неудобно и затратно. Поэтому даже фаулеристы в этом плане осторожны.

Большая контора действительно может иметь десяток никак не связанных изначально систем, которые затем интегрируют. Но каждая из них поддерживается своим коллективом, а интеграция, вполне возможно, ещё одним. И каждый из них предпочитает не распыляться.

а у большинства разработчиков ассоциируются с чем-то древним, сложным и непонятным
Если только разработчик новорожденный или идиот. Если ты не дружишь с СУБД, то коммерческое программирование для тебя ЗАКРЫТО. Либо оно для тебя естественно, либо ты не способен к работе.

Причем как в использовании (зачастую людям приходится осваивать не особенности работы конкретной СУБД, а хитрости и фичи самой IDE), так и в их реализации (поэтому такие системы обычно закрытые и очень платные).

Я начинал с СУБД Firebird, которая мне нравится до сих пор. И не было большой проблемы после неё подружиться с Db2, Oracle, Postgres, H2. С любым из перечисленных можно работать как с простейшей IDE типа SQL Workbench, так я не понимаю чем вам кажется сложным Oracle SQL Developer или PgAdmin 4. Сколько надо от функционала, столько и используете. Если глазки разбегаются, найдите себе за пару часов нужное подмножество функций. На самом деле надо лишь знать сам SQL. И все!

Все больше людей уже не боятся писать код, это становится нормой.
Простите, но даже профессиональный программист наткнувшись на очередную модную штучку вынужден долго курить мануалы и лазить по форумам выискивая особенности работы. Код написать легко, а вот чтобы он хотя бы заработал (неправильно, хотя бы) надо прилично погрузить мозг.
Бабы боятся кода как черт ладана, большинство мужиков относится к нашим правилам как чему-то заумному. Не могу их осуждать. Я тоже не берусь решать проблемы исследования рынков.

Но можем ли мы рассчитывать на него (а заодно и на реляционные БД, с которыми у большинства он плотно ассоциируется) сейчас и в ближайшем будущем, учитывая огромный рост спроса на NoSQL-решения?

SQL может решать почти все проблемы работы с деловыми данными. No-SQL лишь конкретные задачи делает хорошо. Говорить, что No-SQL вытеснит SQL в настоящее время невозможно.

Максим ННу неееет. Например, на моем текущем проекте их применяется аж 3 штуки, и необходимо разбираться в каждой из них (как разработчикам, так и администраторам/DevOps'ам). В других (известных мне) проектах ситуация примерно похожая.


Я сказал, большинство. Обобщать на всех я и не думаю.

Максим НА вы никогда не встречались с разработчиками, которые воспринимают СУБД только в виде ORM? И решают все проблемы с БД способом расстановки Hibernate-аннотаций по коду.

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

Максим НВспоминаю сразу несколько девочек-аналитиков (из разных проектов), которые владели sql'ем на достаточно высоком уровне (включая hint'ы и анализ планов).

У меня за двадцать лет не было ни одного случая, чтобы женщина - не программист работала хоть с каким-то кодом. Разве в универе, на лабах. Женщины программистки существуют в природе, но это большая редкость. Скажем так, моя оценка верна на 98%.

Максим НДа и вообще наверно не очень прикольно делить специалистов по половому признаку (Diversity и все такое...)

Каждый пол имеет свои особенности. Кому хочется уравнивать сосну с березой, ну... В определенном смысле разницы нет, в определенном есть. В том смысле, что я сказал - она есть. :) Давайте не будем тащить западные завихрения сознания в Россию.

Максим НТакого вывода (или даже намека на него) в статье нет.

Согласен, это я уже в общем сказал.

Максим НОпрос (приведенный в статье) был именно среди DBA (а не владельцев компаний или менеджеров), т.е. каждому DBA приходиться разбираться сразу в нескольких СУБД. Примерно похожая картина (уже по личному опыту) и среди разработчиков.

Не согласен насчет разработчиков. Личный опыт говорит обратное. DBA - может быть, это редкий зверь. Как я сказал раньше, в организации обычно зоопарк, но на каждом ОТДЕЛЬНОМ проекте стараются не размножаться.

Максим НДумаю да, многие из них всерьез и надолго связывают с себя с одним конкретным языком программирования. А на то, чтобы погрязать в дебрях той или иной СУБД нет ни времени ни сил. На одном проекте одна СУБД, на другом другая, на третьем третья - лучше выучить ORM (по нему и на собеседованиях будут гонять).

90% разработчиков связаны с конкретным языком программирования. Дельфисты поголовно сидят на конкретной СУБД, очень мало кто из них вкладывается в другую.
Я как джавист могу сказать следующее: я использую лишь подмножество языка SQL. А именно DML. По понятиям Java надо избегать хранимок, триггеров, анонимных блоков...
И собственно, встретив новую СУБД я начинал сходу с ней работать. Не думаю, что я гений и другие так не могут.
90% SQL кода не требует специфики СУБД. Но, например, CONNECT BY в ORACLE слишком серьезно экономит расходы на работу с иерархией, чтобы им пренебречь. 10% не так много, чтобы нельзя было почитать. Тем более это интересно и приносит больше нежели тратится.
Планы исполнения в Firebird добываются/понимаются легче, чем аналогичные в Postgres, но общий принцип един. Тем более, ORM здесь не поможет ничем.

Максим НА в статье я и не акцентировал внимание на "программировании", но говорил про написание кода - "кодирование". Сделать простую страничку на HTML/CSS, оформить документацию в AsciiDoc формате, "нарисовать" диаграмму в PlantUML, написать несложныйy SQL-запрос - разве это программирование? И для этого нужны специальные навыки и "корочки"?

Простите, но подавляющее большинство аналитиков пользуется Word. Никогда аналитик на моей памяти не делал HTML/CSS. Диаграммы они рисуют в Visio. Особенно крутые используют просто другой редактор диаграмм. А чтобы писать SQL... Нет, теоретически несложно, а практически пишут только мужчины тестеры. Девочки-тестеры пишут SQL, когда графический интерфейс становится ну совсем непригоден. Причем пишут руками мальчиков :) Исключения из правил, наверное бывают, но я не сталкивался.
Второй момент - вы уточняйте тогда. По нашим меркам "писать код" == "программировать".