Все зависит от того как писать, если использовать конструкцию with и бить на куски, то 500 строчек sql разбиваются на десяток относительно простых, понятных и легких запросов. Которые можно отлаживать последовательно друг за другом. Не самое приятное дело, но и ничего титанического в этом нет.
Касательно лимита по числу строк, у нас в проекте используется hibernate + нативные запросы через него и именно этот тонкий вопрос различий БД удалось обойти, но можно ли считать его хэлпером )
По текущему опыту переноса относительно крупного проекта могу сказать, что переписывать кучу запросов не пришлось, а в тех случаях где пришлось хэлпер бы не помог. Встретил лишь два типа проблем или отсутствующие функции (nvl, to_number) или работа с boolean.
Есть еще некоторое число больших сложных отчетов, где могут возникнуть проблемы, но их писать в хэлпере не удобно. Sql на 200-500 в подобном виде практически не читаемы и их труднее отлаживать.
Цены на Оракл стали уж совсем неприличными и дешевле залить просевшую производительность железом. Дополнительно в связи с «импортозамещением» бюджетные организации не очень любят оплачивать стоимость этих лицензий и проще уговорить на более мощное железо.
В js используется == в java же он очень редкий зверь годный только для примитивов. Единообразие в синтаксисе сильно повысит читаемость. А предупреждения при компиляции помогут избегать ошибок. Можно же попросить явно аннотировать места где используется именно сравнение по ссылке.
Я из хожу из простого наблюдения, что один и тот же код написаный на js и на java. Читаем на стороне фронта, а вот на стороне сервера вызывает затруднения. К сожалению просто поменять язык сервера нельзя.
К тому же совершенно не понятно, почему для базовой сущности нельзя сделать исключение. Как ниже заметили для строки же это сделали.
Я понимаю, что изменить поведение "==" уже не получиться, но можно хотя бы ввести "===" на сравнение по значению. Это не ломает совместимость. В js уже так поступили.
Ксчастью вам не приходилось постоянно ковыряться в многостраничных текстах арифмитических операций, которые трудно читаемых в любых случаях чуть более отличных от тривиальных.
Писать код вида #define true (Math.random()>0.5) все равно не запретишь. Сейчас это можно размешать внутри equals и радоваться странным результатам. Это не та проблема с которой нужно бороться.
Оператор "==", типы в коллекциях java иммеет много больных мест и при нынешнем ходе развития они никогда не исправяться и не будут исправляться, чтобы не ломать совместимость.
Вся боль, что так как Java это в первую очередь финансовые системы, а все расчеты для них ведутся через стандартный BigDecimal. Работать с остальными примитивами нельзя.
А именно для этого стандартного класса нет удобного способа работы. В итоге приходиться писать все арифметические операции словами.
На изучение возможностей сахара требуется ничтожное количество времени. Вот чтобы изучить, сконфигурировать и настроить простейший сервер, требуется на порядки больше времени и усилий, чем на изучения скажем множественного возврата.
double для финасовых приложений не пригоден. Везде надо использовать BigDecimal, чтобы хотя бы сложение/вычитание работало с абсолютной точностью. Класс же BigDecimal использовать для арифметики не удобно. Простое сравнение с нулем выглядит так
public boolean isZero(BigDecimal val) {
return BigDecimal.ZERO.compareTo(val) == 0;
}
Только вот ни того ни другого в Java нет, а во всех современных языках есть.
Дополнительно из-за отсутствия сахара для свойств в java, в случая любых ограничений (not null/not negative) на поля приходиться постоянно использовать get/set
Касательно лимита по числу строк, у нас в проекте используется hibernate + нативные запросы через него и именно этот тонкий вопрос различий БД удалось обойти, но можно ли считать его хэлпером )
Есть еще некоторое число больших сложных отчетов, где могут возникнуть проблемы, но их писать в хэлпере не удобно. Sql на 200-500 в подобном виде практически не читаемы и их труднее отлаживать.
К тому же совершенно не понятно, почему для базовой сущности нельзя сделать исключение. Как ниже заметили для строки же это сделали.
Оператор "==", типы в коллекциях java иммеет много больных мест и при нынешнем ходе развития они никогда не исправяться и не будут исправляться, чтобы не ломать совместимость.
А именно для этого стандартного класса нет удобного способа работы. В итоге приходиться писать все арифметические операции словами.
В целом вопрос не был бы столь болезненным, если всего для одного! стандартного класса определили бы арифметические операции.
Плюс подобное работает только если работаем с одним объектом. Если входных объектов несколько и есть еще выходной, то данный подход не сработает.
Дополнительно из-за отсутствия сахара для свойств в java, в случая любых ограничений (not null/not negative) на поля приходиться постоянно использовать get/set
Ни в одном современном языке не приходиться писать:
вместо простого и понятного: