Тут есть два аспекта. Гуманитарный. И технический.
На техническом - развоговорный английский стал сленгом и заменой для некоторых слов и выражений.
Есть кроме того непереводимые идеомы и связки которые толком даже не имеют перевода.

Вобщем я лет 10 назад тоже считал что язык Пушкина-Достоевского велик и могуч. Но в деловом
общении главная цель - "быть понятным". И чтобы быть понятным надо просто приобщаться к комьюнити.
Комьюнити на Украине к примеру - достаточно англоязычно и англоицировано чтобы вообще
отказаться от своего языка или диалекта в рабочих вопросах. Тот факт что я еще говорю
на русском - я обязан родителям и хорошей школе. Так бы уже давно писал, как в Oracle пишет модератор SY.
Он кажется ни слова на русском не написал хотя и правила соотв. есть.

Вобщем это вопрос-вкусовщина. Если я - понятен - я пишу так. В диалогах с Усовым я ощутил барьер.
Человек вообще не знает что такое фабрика, компаратор, предикат и прочее. Пришлось ему объяснять. Это
чел на пенсии. Старый мат-меховец. И ему 50% наших слов - белый шум.

Если я для кого-то непонятен - то я могу сойти на его уроветь и объяснить другими словами.

Скажите где и в каком пункте я был непонятен.

Гуманитарный аспект.

Для меня было удивительно как слово "пістолет" превратился "пістолю" а "вертоліт" в "гелікоптер".
Тут не иначе как влияние Польши и Канадской диаспоры на Украину. Ведь в старых языковых
справочниках Української мови та літератури пістолет був пістолетом! забери його чорт!

Честно вообще никого не иммитирую. Я не знаю чей это стиль. Но хорошо. Постараюсь писать по другому.

Я тоже занимался ненужными оптимизациями в части PL/SQL. Я тогда был DBA. Иногда усилия приносили результат. Иногда
нет. Но в 90% случаев эффективнее всего были переговоры с разработчиком и смена постановки. Тоесть попытка
взглянуть на задачу под другим углом. Где-то сортировка была не нужна. Она уходила. Где-то (в одной бухгалтерской
двузвенке) я применил чудовищно сложный паттерн. Что-то вроде получения остаточной процедуры PLSQL после
свёртывания констант. Но в результате исходник стал в 10 раз больше и сложнее в сопровожднии. Прирост
производительности был получен. Где-то на 50%. Бухгалтерские проводки пошли быстрее. Ну там вместо 8 часов 4 часа.
Но этот исходник прожил 1 месяц и был випилен на следующей-же итерации бизнес-задач.

Василий. Забей. Никакие не чеканные. Это просто моя лень ставить запятые.

Еще пункт. Data flow. Данные должны - как можно меньше двигаться.
Каждый день - смотреть на диаграмму движения и думать и думать
как от этого движения уйти.

Идеальная система - это как камень у древних Греков. Неподвижная.

Давай обсудим. Вот возник такой бизнес-факт. Я купил стаканчик Капучино за 2.15€ сегодня в 12:01.
И этот бизнес факт лег в платёжную систему. И какие изменения и порождения новых данных
ты предполагаешь?

Да СУБД очень легко задизайнить неправильно. Например втащить EAV или Квинтеты в ту задачу
где они будут мешать перформансу. Хотя на демо-версии все будет чики-пики ведь данных то еще
мало. А когда данные вырастут в 10 или 100 или 1000 крат тогда окажется что и план выполнения
плохой. И исправить нельзя. 1 универсальная табличка EAV уже проиндексирована так что уже
и некуда новый индекс ставить. А аналитика все равно плохо идет.