Исправление MichIs, (текущая версия) :
Тохо2, я уже перестал спорить с нашими оппонентами, как я понял, в основном Java-истами, чей язык и технологии (монстроузные сервера приложений, orm, и т.д.) понемного-потихоньку сходит с арены, уступая место другим современным языкам как C#, Kotlin, Scala, Python, Go, Rust.
Для меня очевидно, что они недостаточно глубоко разбираются в СУБД, тем более в Oracle, иначе они не пороли бы той чуши и дичи, которую они осветили выше. Если бы они знали Oracle получше, то им бы было известно, что их любимая Java наряду с PL/SQL имеется внутри Oracle DB, что на ней можно писать и хранимки, и триггеры. Но никто из нормальных разработчиков СУБД это не делает, а используют только в очень редких случаях (у меня такой был - кода надо было выковыривать текст из PDF-документа, который складывался в определенную директорию)
Ну и понятие стоимости и скорости разработки с СУБД, а также кол-ва железа, серверов и не побоюсь этого слова Кластеров :) требуемых для обработки данных на их ORM за пределами СУБД, в их рассуждения не входит.
Ну и как следствие незнания СУБД, orm-щики пытаются натянуть «сову на глобус» - пытаясь применить свой, не всегда адекватный и релевантный опыт трахания с ORM к работе внутри СУБД.
ORM-щикам хорошо бы заучить следующие Правила и приоритеты выбора Языка программирования при создании приложений на Oracle DB:
ПС. там кто-то про «параллельность» писал, мол нет ее в PL/SQL. Так вот «праллельность» в Oracle обеспечивается самой СУБД, обрабатывающией множество заросов от множества сессий. Также есть средства распаралеливания запросов, вставок, обновлений (если к то в курсе, а то, может, ORM-щики этого не знают). И по той же Java, которая внутри Oracle есть настоятельная рекомендация в документации Oracle - не использовать встроенные в Java средства многопоточности (объяснение смотри выше + нехорошо, когда криво написанная программа на Java с многопоточностью завалит весь сервер СУБД). ссылка
Исправление MichIs, :
Тохо2, я уже перестал спорить с нашими оппонентами, как я понял, в основном Java-истами, чей язык и технологии (монстроузные сервера приложений и т.д.) понемного-потихоньку сходит с арены, уступая место другим современным языкам как C#, Kotlin, Scala, Go, Rust.
Для меня очевидно, что они недостаточно глубоко разбираются в СУБД, тем более в Oracle, иначе они не пороли бы той чуши и дичи, которую они осветили выше. Если бы они знали Oracle получше, то им бы было известно, что их любимая Java наряду с PL/SQL имеется внутри Oracle DB, что на ней можно писать и хранимки, и триггеры. Но никто из нормальных разработчиков СУБД это не делает, а используют только в очень редких случаях (у меня такой был - кода надо было выковыривать текст из PDF-документа, который складывался в определенную директорию)
Ну и понятие стоимости и скорости разработки с СУБД, а также кол-ва железа, серверов и не побоюсь этого слова Кластеров :) требуемых для обработки данных на их ORM за пределами СУБД, в их рассуждения не входит.
Ну и как следствие незнания СУБД, orm-щики пытаются натянуть «сову на глобус» - пытаясь применить свой, не всегда адекватный опыт трахания с ORM к работе внутри СУБД.
ORM-щикам хорошо бы заучить следующие Правила и приоритеты выбора Языка программирования при создании приложений на Oracle DB:
ПС. там кто-то про «параллельность» писал, мол нет ее в PL/SQL. Так вот «праллельность» в Oracle обеспечивается самой СУБД, обрабатывающией множество заросов от множества сессий. Также есть средства распаралеливания запросов, вставок, обновлений (если к то в курсе, а то, может, ORM-щики этого не знают). И по той же Java, которая внутри Oracle есть настоятельная рекомендация в документации Oracle - не использовать встроенные в Java средства многопоточности (объяснение смотри выше + нехорошо, когда криво написанная программа на Java с многопоточностью завалит весь сервер СУБД). ссылка
Исправление MichIs, :
Тохо2, я уже перестал спорить с нашими оппонентами, как я понял, в основном Java-истами, чей язык и технологии (монстроузные сервера приложений и т.д.) понемного-потихоньку сходит с арены, уступая место другим современным языкам как C#, Kotlin, Scala, Go, Rust.
Для меня очевидно, что они недостаточно глубоко разбираются в СУБД, тем более в Oracle, иначе они не пороли бы той чуши и дичи, которую они осветили выше. Если бы они знали Oracle получше, то им бы было известно, что их любимая Java наряду с PL/SQL имеется внутри Oracle DB, что на ней можно писать и хранимки, и триггеры. Но никто из нормальных разработчиков СУБД это не делает, а используют только в очень редких случаях (у меня такой был - кода надо было выковыривать текст из PDF-документа, который складывался в определенную директорию)
Ну и понятие стоимости и скорости разработки с СУБД, а также кол-ва железа, серверов и не побоюсь этого слова Кластеров :) требуемых для обработки данных на их ORM за пределами СУБД, в их рассуждения не входит.
Ну и как следствие незнания СУБД, orm-щики пытаются натянуть «сову на глобус» - пытаясь применить свой, не всегда адекватный опыт трахания с ORM к работе внутри СУБД.
ORM-щикам хорошо бы заучить следующие Правила и приоритеты выбора Языка программирования при создании приложений на Oracle DB:
Исходная версия MichIs, :
Тохо2, я уже перестал спорить с нашими оппонентами, как я понял, в основном Java-истами, чей язык понемного-потихоньку сходит с арены, уступая место другим современным языкам как Go, Rust, Scala.
Для меня очевидно, что они недостаточно глубоко разбираются в СУБД, тем более в Oracle, иначе они не пороли бы той чуши и дичи, которую они осветили выше. Если бы они знали Oracle получше, то им бы было известно, что их любимая Java наряду с PL/SQL имеется внутри Oracle DB, что на ней можно писать и хранимки, и триггеры. Но никто из нормальных разработчиков СУБД это не делает, а используют только в очень редких случаях (у меня такой был - кода надо было выковыривать текст из PDF-документа, который складывался в определенную директорию)
Ну и понятие стоимости и скорости разработки с СУБД, а также кол-ва железа, серверов и не побоюсь этого слова Кластеров :) требуемых для обработки данных на их ORM за пределами СУБД, в их рассуждения не входит.
Ну и как следствие незнания СУБД, orm-щики пытаются натянуть «сову на глобус» - пытаясь применить свой, не всегда адекватный опыт трахания с ORM к работе внутри СУБД.
ORM-щикам хорошо бы заучить следующие Правила и приоритеты выбора Языка программирования при создании приложений на Oracle DB: