Компромисс будет всегда
Вы могли уже решить, что пора переписывать массу кода. Но, написание кода, генерирующего идеальный SQL-оператор каждый раз, повышает вероятность ошибок. Компромисс между повышенным риском ошибки (а также временем на кодирование, тестирование и отладку) и производительностью всегда будет, так что, если сервер далек до полной загрузки, вполне допустимо и обоснованно будет игнорировать все описанные выше проблемы. По крайней мере, в краткосрочной перспективе.
Есть и еще один, более тонкий компромисс. Если приложение генерирует идеальный SQL-оператор для каждого обновления, которое оно потенциально может сгенерировать конечное приложение, то существенно возрастает количество различных SQL-операторов в системе.
Теоретически, если в таблице есть N столбцов, тогда разных операторов update может быть power(2,N) - 1, и это если ограничиться только однострочными обновлениями по rowid. Если не увеличить соответственно разделяемый пул и не настроить несколько параметров, вроде session_cached_cursors, может оказаться, что экономия в одном месте оборачивается дополнительными проблемами (такими как конфликты доступа к библиотечному кэшу) в другом.
