Вы думаете, что в 90х было как то по другому?

Тогда подавляющее большинство систем с БД тоже разрабатывались не-БД программистами.
Просто называлось это по другому - не было ORM, но были формочки и таблички, которые мышкой привязывались к базе данных и таблицей в ней.
И вот этот кошмар плавно перешёл в EF, ORM и т.п.
И конечно, DBD/DBA с такими системами не работали тогда, и не работают сейчас.
Но процентное соотношение примерно такое же. Недостаточно в постах упомянуть "легаси" и намекнуть на замшелось, что бы высказывания стали верными

По вашему, независимо от сложности и размеров системы, она после тестирования не должна ни разу сбойнуть следующие несколько десятилетий эксплуатации? Нужно просто нанять хороших разработчиков, и провести полное тестирование? Или даже, как сейчас часто пишут, не нанять хороших, нужно просто "поставить процессы"? И при эксплуатации не нужны будут никакие админы?

Не соглашусь с этим.

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

Собственно, в начале 90х мне это точно так же доказывали программисты того времени. Какой DBA, какой DBD, я мышкой базу нарисовал, таблички на формочки перетянул, остальное сделают новейшие средства разработки VB/Delphi - и не нужны эти ковыряния в SQL коде.

Но вот, работает это не всегда.
Вот это "ориентированные на данные системы" встречается достаточно часто, даже без чего то особо навороченного.
Скажем, у Волмарта есть база чеков - простая и не особо большая, пара таблиц побольше, для чеков, и десяток маленьких. Сколько там у них магазинов, тыщ 10? Ну, по тыщ по 100 строк чеков в день.
И год за годом пишут разные команды какие то приложения к этим несчастным табличкам.

Кто эти таблички должен разрабатывать? Кто поддерживать? Регламентировать доступ?
Вот это как раз работа для спецов по базам.

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

А мелкие разработки, когда база есть принадлежность приложения - они и раньше часто обходились без DBA

А что вы понимаете под легаси? Под этим подразумевают системы, платформы, которые уже массово не распространены, не поддерживаются, не выпускаются. Например, база на IBM 370 или Novell

Ок, допустим, в Волмарте система работает на мейнфреймах, перфокартах, ну и вашей команде поручили это дело переработать.
Сделать базу данных, которая будет потом эксплуатироваться следующие 30 лет, а к ней какие то люди в каких то странах будут писать клиентов (для компов, смартфонов, искусственного интеллекта, может, писать через 30 лет будет сам искусственный интеллект - но данные будут логически те же, потому что это данные от бизнеса, они не изменятся, пока не изменится бизнес).
Кто, интересно, стыл бы у вас это делать, какие специалисты?
И как вы тут будете использовать APP-сервера, и, главное, зачем? И захочет ли это клиент, если вы ему предложите вместо СУБД сделать всё на APP-серверах, как вы сможете ему показать, что такая разработка будет проще, и показать, что будет потрачено меньше денег на сопровождение?

То есть, я не говорю, что многоуровневая архитектура с APP-серверами плоха, я просто говорю, что есть такой подход - проектировать работу с данными как уровень архитектуры. Это часто используется для проектов с долго-живущими (десятилетиями) данными, типа тех же волмартовских продаж или карточных банковских систем. Вполне разумно такую базу разработать узким специалистам по СУБД, а не, крича "APP-сервер! современно! ORM!" отдать это java-программистам

Я со старыми системами не работал, не приходилось, на каких то работах вливался в разработку/эксплуатацию, а на каких то делал систему с нуля, а потом её несколько лет поддерживал. Делали такие проекты обычно на новой свежепоявившейся платформе, тупо что бы срок поддержки производителем был побольше, ничего старого не использовали.
Так что никаких легаси, всё современное.
И при этом делали уровень работы с данными на стороне базы данных, с хранимыми процедурами и т.п. Что есть очень современный и прогрессивный подход. Впрочем, некоторые большие проекты из этого и состояли; клиентские приложения если и делались, то как дополнение, отдельными людьми/командами (да, с апп-серверами, конечно, никаких прямых обращений к базе не помню уже лет 20).

Данные полезны, но систему, которая их хранит и обрабатывает, нужно переписывать раз в год? Почему, "потому что это несовременно"?
Бизнес так не делает. На производстве работают станки 30х годов, в авиации летают самолёты 30 летней давности, в ритейле работают базы 90х, зачем уничтожать актив, успешно работающий и приносящий деньги? Ах да, что бы уволить DBA, сэкономить на его зарплате. Правда, вместо него нужно будет держать команду разработчиков, ведь это современно, а DBA - это устаревший легаси Это просто слова, я про свои места работы тоже могу сказать "к примеру за подобные ответы на собеседовании (на позицию девелопера) вас-бы уже отправили домой" Эээ, это вы писали "дата-ориентированные системы это мейнфрейм с перфокартами"? Я писал совсем другое. "мейнфрейм с перфокартами" - это я писал про понятие легаси.

А про "дата-ориентированные системы" я писал, что это системы, которые ориентированны на данные, но естественно, я подразумеваю, что с их обработкой, то есть с бизнес-логикой. Но без пользовательского интерфейса.
Для таких систем есть специально предназначенные технологии, например, Хадуп. Или РСУБД, если эти данные реляционные.
И есть специалисты по этим технологиям. Я же подробно описал, какие могут быть неоднозначности?
Команда делает базу, бизнес-логику, клиент платит.

Потом клиент хочет пользовательский веб-интерфейс, создаётся ещё команда, пишет, клиент использует, платит.
Потом клиент хочет интерфейс Хололинз. и мобильный для андроида и айфона, создаётся ещё команда, пишет, клиент использует, платит.
Потом клиент хочет пользовательский веб-интерфейс, но другой, первый не понравился - делали на сильверлайт, а он кирдык, создаётся ещё команда, пишет, клиент использует, платит.

В этих командах да, используют АПП-серверы. Я с ними знаком, иногда совместно что то делаем, но особенно я не в курсе их работы, не вникаю.

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