mad_nazgulПо мне ХП - это зло.
Вносит грязь императивщины в чистоту декларативного ЯП. :-)

Костыль из-за ограниченности реляционной модели.
Вместо того, чтобы реализовать логику в другом ЯП, который для этого предназначен, наделали несовместимых костылей, которые каждый вендор делает по собственному вкусу.
При подходе "вся логика в хранимках" промежуточный слой в виде, например Java и сервера приложений, не нужен.
Что почти успешно проделали Oracle, но не дожали.
Сейчас тренд идет от отхода реализации бизнес-логики в ХП.
Причем это не из-за "возможностей" ЯП, а чисто по организационным причинам.
Сопровождать проекты, например на Java, проще, чем на ХП.
Да не, не так категорично, вадя, конечно, несет много всякого разного бреда, но он прав в мысли о том, что инструмент нужно использовать по назначению, например, для разработки DWH ХП действительно весьма полезны, более того, без них там ну вообще никак (за попытку прикрутить JPA в DWH сразу надо расстреливать, за вредительство). А вот когда у вас колотилка данных с доменкой, в которой разувесистые связи между сущностями, то тут ORM наше все и в топку хранимки.

вадяк примеру хранимки в mssql компилируются, для повышения быстродействия.
К примеру JIT-компилятор есть, как в JVM и соответственно Java код тоже компилируется для повышения быстродействия, так и, вы не поверите, но и в браузерных движках, например, в V8 тоже работает JIT компилятор и да, это означает, что javascript тоже компилируется. Удивительно?

вадяjust_vladimirК примеру JIT-компилятор есть, как в JVM и соответственно Java код тоже компилируется для повышения быстродействия, так и, вы не поверите, но и в браузерных движках, например, в V8 тоже работает JIT компилятор и да, это означает, что javascript тоже компилируется. Удивительно?
хороший пример как подменяют факты.
путают мух и котлеты.....
если ты чего-то не знаешь - не суйся.
А по сути есть что написать или только какашками кидаться, какие все неучи вокруг, дак снизойди, расскажи, где я неправ?

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

Какая то надуманная проблема, то что mysql не помнит результатов компиляции ранее выполнявшихся запросов, то это исключительно проблемы mysql, кстати, о ней в этом топике пишете только вы. Все нормальные СУБД это хранят, в Oracle это library cache если мне не изменяет память. И самое главное как связаны проблемы MySQL и ваше мнение о том, что хранимки в MSSQL круче кода на Java, потому что они компилируются?

вадяи все потуги реализовать подобное на java просто выглядят смешно.
Зачем реализовывать, в Java по умолчанию весь более менее "горячий" код компилируется, ничего писать не надо, это встроено в виртуальную машину.

вадяи вопрос как будет читаться запрос в java на несколько экранов? а как его отлаживать?
Какой запрос на несколько экранов? как это вообще связано с наличием или отсутствием возможности компилировать тот или иной код? Кстати, отладка Java кода в 100500 раз удобней отладки какого-нибудь PL/SQL.

вадякомпилировать весь код java?
И еще раз, в JVM используется Just In Time компилятор, то есть он и так компилируется, в 9-ке будет AOT компилятор для желающих.

вадяскопировать строку из кода java со всеми артефактами строки? которые нужно убрать и потом опять вставить?
прокладки не рассматриваю в силу их ущербности.
Этот набор слов вообще не осилил, какие артефакты строки, откуда и куда вы их хотите убирать и как это связано с тем, компилируется ли java или нет?

вадяя говорю о реализации того, что на что ориентирована субд - кодом java.
на всё осталное нет смысла отвечать - просто придирки к словам....
Как вы ловко открестились от своего заявления, что код в ХП лучше кода в Java, тем что он там компилируется и заменили это тем, что нужно сравнить вообще в принципе факт использования СУБД и создания своего велосипеда вместо СУБД на Java... Это уже совершенно другая история.
Хотя и такие варианты есть, почитайте про In-memory Data Grid, сам грид реализован на Java и среди прочего поддерживает ANSI SQL-99.