Petro123mad_nazgul"Унутре у нее неонка!"
прикольно.
Но тут объектов то и нету).
Т.е. где БЛ или сервисный слой.
Т.к. без него и АппСервер не нужен.

Так я про это и говорю!
Если вам не нужен сервисный слой, то ОРМ это идеальное решение.
Но как только нужно что-то более "интеллектуальное", то ОРМ идет лесом.
Т.к. затраты на поддержания такого сервисного слоя не оправдываются "удобствами" ОРМ.

вадяmad_nazgulГрубо говоря инструментарий для написания ХП и поддержки кодовой базы почти у всех вендоров находятся в зачаточном состоянии.
тоже спорное утверждение-
у ms очень хороший инструмент
у mysql счас даже два очень приличных


Например?
Какая система контроля версий существует для MS или My SQL?
Как можно вести более одной ветки БД с ХП.
И их разнообразными слияниями.
Часть ХП в одной ветке, часть в другой.
И мы м/у ними какие-то ХП перекидываем.
Для кодовой базы на других ЯП.
Это не проблема, ибо это текст.
С ХП это не так, т.к. это более чем текст.

вадяmad_nazgulКроме того, в пределе при таком подходе, не нужен слой "сервера приложений".
ну это аргумент в пользу бедных...
вообще это признание огромных возможностей хранимок - всех что пишут "серверы пприложений" можно послать... ну кто под такое подпишется ? вот и хають..


У меня претензии к "классическим" ХП (ну кроме ХП в PostgreSQL, это которые пишутся на встроенном движке, а не plpgsql)
В том что они реализуют императивную парадигму в декларативном ЯП.
По мне это костыль.
Причем, который почему-то выдают за достоинство.

А насчет, того что можно вместо 3-х уровневой архитектуры делать 2-х уровневою.
Так я об этом и говорю.
Если начали писать на бизнес-логику ХП, сразу надо выкидывать средний слой (сервер приложений).

Иначе он будет, что-то вроде spring-data-jpa, и его можно будет генерировать автоматом, без программистов.

Я бы согласился, чтобы так и было.
Но проблема в том, что средства за управлением кодом во всех актуальных СУБД, в зачаточном состоянии.
Системы контроля версий нет, от слова совсем.
А т.к. ХП прибиты гвоздями к данным, то выделить их в отдельную сущность очень затруднительно.

Так что противник использования ХП в разработке.
В администрировании - да.
Вполне удобный рабочий инструмент.

вадяmad_nazgulНа сколько я понял, потому что поддерживать такие решения оказалось дороже, чем переписать с нуля.
это вообще не аргумент. дороже - в чём дороговизна ?
а не дороже ли городить на других языка код дублирующий (в слабом подобии) возможности субд?

Как раз это основной аргумент.
Что стоимость внесения изменений стала такой, что дешевле стало нанять других программистов, которые переписали приложение с нуля.

вадяПылинка... видимо когда-то была мечта - использовать java-программистов, не знающих sql.как подтверждение этому - при приёме java прогеров практически нет требований к знанию sql

С точностью до наоборот.
Знание SQL это основное требование к Java/C# программистам.

вадяmad_nazgul,

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


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

Кстати я про него и говорю.
Это основа командной работы.
Когда над разными участками кода могут работать сотрудники разнесенные территориально.

Gluck_13(Entity Framework 6, допиливали непосредственно в исходниках), мы перевели примерно 80% хранимок в код сервера приложений с минимальными потерями в производительности (а где-то удалось и оптимизировать быстродействие).

Блин.
У MS была почти идеальная ORM, которую могли бы развивать, но ее убили.
Это я о FoxPro :-)

вадяmad_nazgulКак раз отсутствие развитой системы контроля версий похоже и убило программистов DB.
как говорят про плохого танцора, что ему вечно что-то мешает....

Аналогия не верна.
Если так говорить...
У танцоров проблем нет.
Вот только платят не за танцы, а за песни. :-)

WGAmaytonОй не говори. Приходим с конференций Спринг-Бут и облизываемся.Правильное название "Спринг-Слоу-Бут" ))

Ну и что?
WebSphere или JBoss, например, грузятся еще медленнее, чем spring-boot. :-)