История изменений

Тохо2, я уже перестал спорить с нашими оппонентами, как я понял, в основном Java-истами, чей язык и технологии (монстроузные сервера приложений, orm, и т.д.) понемного-потихоньку сходит с арены, уступая место другим современным языкам как C#, Kotlin, Scala, Python, Go, Rust.

Для меня очевидно, что они недостаточно глубоко разбираются в СУБД, тем более в Oracle, иначе они не пороли бы той чуши и дичи, которую они осветили выше. Если бы они знали Oracle получше, то им бы было известно, что их любимая Java наряду с PL/SQL имеется внутри Oracle DB, что на ней можно писать и хранимки, и триггеры. Но никто из нормальных разработчиков СУБД это не делает, а используют только в очень редких случаях (у меня такой был - кода надо было выковыривать текст из PDF-документа, который складывался в определенную директорию)

Ну и понятие стоимости и скорости разработки с СУБД, а также кол-ва железа, серверов и не побоюсь этого слова Кластеров :) требуемых для обработки данных на их ORM за пределами СУБД, в их рассуждения не входит.

Ну и как следствие незнания СУБД, orm-щики пытаются натянуть «сову на глобус» - пытаясь применить свой, не всегда адекватный и релевантный опыт трахания с ORM к работе внутри СУБД.

ORM-щикам хорошо бы заучить следующие Правила и приоритеты выбора Языка программирования при создании приложений на Oracle DB:

Используйте SQL где можно (имеется ввиду в процедурах PL/SQL)
Если SQL не может решить всех поставленных задач, используйте PL/SQL (имеется ввиду логика, структуры, web-стредства и т.д.)
Если PL/SQL не может решить всех поставленных задач, используйте Java (обернутые в процедуры PL/SQL)
Если Java не может решить всех поставленных задач, используйте C/C++

ПС. там кто-то про «параллельность» писал, мол нет ее в PL/SQL. Так вот «праллельность» в Oracle обеспечивается самой СУБД, обрабатывающией множество заросов от множества сессий. Также есть средства распаралеливания запросов, вставок, обновлений (если к то в курсе, а то, может, ORM-щики этого не знают). И по той же Java, которая внутри Oracle есть настоятельная рекомендация в документации Oracle - не использовать встроенные в Java средства многопоточности (объяснение смотри выше + нехорошо, когда криво написанная программа на Java с многопоточностью завалит весь сервер СУБД). ссылка

Тохо2, я уже перестал спорить с нашими оппонентами, как я понял, в основном Java-истами, чей язык и технологии (монстроузные сервера приложений и т.д.) понемного-потихоньку сходит с арены, уступая место другим современным языкам как C#, Kotlin, Scala, Go, Rust.

Для меня очевидно, что они недостаточно глубоко разбираются в СУБД, тем более в Oracle, иначе они не пороли бы той чуши и дичи, которую они осветили выше. Если бы они знали Oracle получше, то им бы было известно, что их любимая Java наряду с PL/SQL имеется внутри Oracle DB, что на ней можно писать и хранимки, и триггеры. Но никто из нормальных разработчиков СУБД это не делает, а используют только в очень редких случаях (у меня такой был - кода надо было выковыривать текст из PDF-документа, который складывался в определенную директорию)

Ну и понятие стоимости и скорости разработки с СУБД, а также кол-ва железа, серверов и не побоюсь этого слова Кластеров :) требуемых для обработки данных на их ORM за пределами СУБД, в их рассуждения не входит.

Ну и как следствие незнания СУБД, orm-щики пытаются натянуть «сову на глобус» - пытаясь применить свой, не всегда адекватный опыт трахания с ORM к работе внутри СУБД.

ORM-щикам хорошо бы заучить следующие Правила и приоритеты выбора Языка программирования при создании приложений на Oracle DB:

Используйте SQL где можно (имеется ввиду в процедурах PL/SQL)
Если SQL не может решить всех поставленных задач, используйте PL/SQL (имеется ввиду логика, структуры, web-стредства и т.д.)
Если PL/SQL не может решить всех поставленных задач, используйте Java (обернутые в процедуры PL/SQL)
Если Java не может решить всех поставленных задач, используйте C/C++

ПС. там кто-то про «параллельность» писал, мол нет ее в PL/SQL. Так вот «праллельность» в Oracle обеспечивается самой СУБД, обрабатывающией множество заросов от множества сессий. Также есть средства распаралеливания запросов, вставок, обновлений (если к то в курсе, а то, может, ORM-щики этого не знают). И по той же Java, которая внутри Oracle есть настоятельная рекомендация в документации Oracle - не использовать встроенные в Java средства многопоточности (объяснение смотри выше + нехорошо, когда криво написанная программа на Java с многопоточностью завалит весь сервер СУБД). ссылка

Тохо2, я уже перестал спорить с нашими оппонентами, как я понял, в основном Java-истами, чей язык и технологии (монстроузные сервера приложений и т.д.) понемного-потихоньку сходит с арены, уступая место другим современным языкам как C#, Kotlin, Scala, Go, Rust.

Для меня очевидно, что они недостаточно глубоко разбираются в СУБД, тем более в Oracle, иначе они не пороли бы той чуши и дичи, которую они осветили выше. Если бы они знали Oracle получше, то им бы было известно, что их любимая Java наряду с PL/SQL имеется внутри Oracle DB, что на ней можно писать и хранимки, и триггеры. Но никто из нормальных разработчиков СУБД это не делает, а используют только в очень редких случаях (у меня такой был - кода надо было выковыривать текст из PDF-документа, который складывался в определенную директорию)

Ну и понятие стоимости и скорости разработки с СУБД, а также кол-ва железа, серверов и не побоюсь этого слова Кластеров :) требуемых для обработки данных на их ORM за пределами СУБД, в их рассуждения не входит.

Ну и как следствие незнания СУБД, orm-щики пытаются натянуть «сову на глобус» - пытаясь применить свой, не всегда адекватный опыт трахания с ORM к работе внутри СУБД.

ORM-щикам хорошо бы заучить следующие Правила и приоритеты выбора Языка программирования при создании приложений на Oracle DB:

Используйте SQL где можно (имеется ввиду в процедурах PL/SQL)
Если SQL не может решить всех поставленных задач, используйте PL/SQL (имеется ввиду логика, структуры, web-стредства и т.д.)
Если PL/SQL не может решить всех поставленных задач, используйте Java (обернутые в процедуры PL/SQL)
Если Java не может решить всех поставленных задач, используйте C/C++

Тохо2, я уже перестал спорить с нашими оппонентами, как я понял, в основном Java-истами, чей язык понемного-потихоньку сходит с арены, уступая место другим современным языкам как Go, Rust, Scala.

Для меня очевидно, что они недостаточно глубоко разбираются в СУБД, тем более в Oracle, иначе они не пороли бы той чуши и дичи, которую они осветили выше. Если бы они знали Oracle получше, то им бы было известно, что их любимая Java наряду с PL/SQL имеется внутри Oracle DB, что на ней можно писать и хранимки, и триггеры. Но никто из нормальных разработчиков СУБД это не делает, а используют только в очень редких случаях (у меня такой был - кода надо было выковыривать текст из PDF-документа, который складывался в определенную директорию)

Ну и понятие стоимости и скорости разработки с СУБД, а также кол-ва железа, серверов и не побоюсь этого слова Кластеров :) требуемых для обработки данных на их ORM за пределами СУБД, в их рассуждения не входит.

Ну и как следствие незнания СУБД, orm-щики пытаются натянуть «сову на глобус» - пытаясь применить свой, не всегда адекватный опыт трахания с ORM к работе внутри СУБД.

ORM-щикам хорошо бы заучить следующие Правила и приоритеты выбора Языка программирования при создании приложений на Oracle DB:

Используйте SQL где можно (имеется ввиду в процедурах PL/SQL)
Если SQL не может решить всех поставленных задач, используйте PL/SQL (имеется ввиду логика, структуры, web-стредства и т.д.)
Если PL/SQL не может решить всех поставленных задач, используйте Java (обернутые в процедуры PL/SQL)
Если Java не может решить всех поставленных задач, используйте C/C++