alexeyshkolnik

Аргумент о том, что будем менять БД не подходит, БД менять ближайшие 10 лет не собираемся

этот аргумент кочует лет 20, причем не только в отношении БД, а вообще всего.

В PHP, например, абстракция PDO - почти такой же надуманный предлог, мол, а если база поменяется?

Вот когда поменяется база, наймут новых разработчиков и они будут заново пилить и переписывать. Потому, что ПО ФАКТУ со сменой базы меняется всё - начиная с формата получения данных в клиентском коде и заканчивая теми участками, где используются какие-то фитчи конкретной СУБД, как, например, в MySql ONLY_FULL_GROUP_BY без которого SQL на другой базе попросту не сработает или функции, специфичные для бывшей/текущей БД.

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

Между тем, адепты не писать логику в БД почему-то тихо "игнорируют" такие вещи, как внешние ключи и такие вещи как ON DELETE CASCADE с удовольствием используют, а не пишут цикл перебора с методом delete для каждой из связанных сущностей.

Вам указывали недостатки, но, почему-то для вас "Всё минусы какие-то мутные (кроме зависимости от конкретной БД)".
Давайте попробуем посмотреть повнимательнее:
1. Сложность отладки и тестирования - в то время, когда я работал с такими приложениями была проблема с тем, что средства отладки были слишком неразвиты, зачастую приходилось пользоваться dbms_output и все, чтобы отладить процедуру. думаю, нормыльные даббагеры потом появились, но я уже к тому времени ушел. Как сейчас обстоит с этим в РСУБД?
2. Затрудненная версионность - а разве не так? На больших проектах со множеством разработчиков это ещё как будет стрелять. Просто посмотрите как мучаются люди с данной проблемой https://habr.com/ru/articles/330662/, тогда как те, кто использует БЛ вне базы просто пользуются гитом
3. Зависимость от конкретной СУБД. Вы уверены, что БД у вас всегда будет подходить под требования бизнеса на 10 лет? Что, если за 10 лет появятся задачи, которые лучше решать другими инструментами? А если появятся задачи которые можно решить только сторонними инструментами?
4. "Ограниченные возможности языка" - можно ли решить все проблемы с помощь SQL/PL-SQL?
5. Сложности с масштабированием/оптимизацией - здесь тоже намного сложнее все. Кэширование вы тоже на СУБД будете возлагать? Что будет, когда у вас серверов БД будет больше 1?
6. Что насчет интеграций? Что будет, если вам надо будет ходить по АПИ в третьесторонний сервис? вы это тоже заложите в логику в БД?

Можно. Весь 20-й век почти так делали. База была главной. Эдакая себе царица. Ее любили. Холили.
Приложения были двухзвенки. Оконная апликуха коннектилась к базе и все расчеты
проводились в базе. Апликуха только показывала результаты в гридах и вводила формочки.
Джобы тоже запускались в базе как процедуры на PL/SQL по скедулеру. Для пуска их клиент
был тоже не нужен. Плановые задачи БД запускала самостоятельно. Это и было видение
бизнес логики из 20-го века.

В 21-м веке с развитием веба появился слой middle. И разработчики вынесли в него максимальную
часть логики. Это произошло естественным путем. А базе досталась участь быть просто хранилищем
таблиц. Потому что держать 2 копии логики или поддерживать было уже неудобно. В команде
должен быть тогда разработчик и Java и PL/SQL одновременно. В современной парадигме
разработки с ORM база стала просто чем-то вторичным. И на уровне ORM абстракций
даже заменяемым на другие типы баз.

Но не все так плохо.

Фактически, логика современного приложения размазана по 3м слоям. Даже в браузере
есть какая-то минимальная логика, например при аутентификации или при проверке
валидности емейла. И какая-то логика агрегации (sum/group by) полюбому есть в базе.
Потому что агрегировать в приложении все - глупо. Это лишний трафик.

И нет такого архитектора который говорит "нельзя". Просто есть best-practices современной разработки,
исходя из развитя железа, сетей и вообще рынка всего остального. Кто знает может в мобилах вернуться
к двузвенкам. Смотря под каким углом смотреть на современные мобильные приложения? Who knows.

Лучше делать сервер, используя NIO.
Пример: www.java2s.com/Tutorial/Java/0320__Network/UDPEcho...