Здравствуйте, amironov79, Вы писали:

A>Проведите опрос среди базовиков: на каком языке пишутся хранимые процедуры? Думаю, подавляющее большинство не будет знать ничего за пределами plsql/tsql. А если будут, спросите про язык первого выбора для написания хранимки? Думаю 99.99% скажут про plsql/tsql.
А если опросить фронтендеров про расшифровку SOLID, то 99% не смогут ответить.
Ну и что? Мы обсуждаем здесь не невежество отдельных представителей профессии, а правильные ответы на сложные вопросы.

A>Я про пиар, а не про документацию. У оракла java stored procedures тоже очень хорошо описаны. Но кто про это знает?
Все, кому интересно .
A>И что смешного? Если система большей частью завязана на проприетарный язык, то портировать ее на другую базу практически невозможно, только переписать. А значит разработчики и пользователи этой системы будут постоянными покупателями данной субд. Разве это неочевидно?
Очевидно то, что синтаксис языка играет десятую роль. Всё упирается в нюансы: как устроено взаимодействие с контекстом. Даже если держать всю логику внутри апп.сервера, портирование на другую СУБД — это тот ещё квест.
В реальности написание хранимок на управляемом языке только усугубляет вендор-лок.

A>Для меня намного удобнее, прямо небо и земля. Другим надо русскую документацию, обучение по новому для них языку, интеграцию со средой разработки (чтобы им настроили и ткнули пальцем куда код писать), ну и распоряжение руководства, конечно же.
Всё это уже есть. И документация, и тьюториалы, и интеграция с MS VS. Распоряжение вашего руководства, увы, Редмонд обеспечить не в состоянии.
Да и вообще — руководству, ему ведь помогать надо. Оно "распоряжается" не на пустом месте; работа архитектора — принять решение и обосновать его. Обоснует pl/sql — будут писать на pl/sql. Обоснует java — будут писать на java. Обоснует хранимки на java в oracle — будут писать хранимки на java.
Вот, этот форум — он как раз для архитекторов.