softwarerРоман... в предыдущем аргументе Вы показали нежелание подумать над сказанным мной. В этом аргументе - демонстрируете, что либо не читали написанного мной, либо осознанно проигнорировали это.
При таком отношении собеседника к разговору я в 100% случаев прекращаю беседу. Dixi.
Я всегда рад внимательно прочитать и подумать, но не додумывать за собеседника.
Во избежании недопонимания, просто рекомендовал бы выражаться конкретнее, а не обтекаемыми абстрактными двусмысленными фразами.
Вы предлагаете писать "хорошо", но по сути конкретно не предлагаете никакой roadmap, ни аналогов, ни примеров.
В итоге разговор приобретает бессмысленность или сводится к "что для русского хорошо, то немцу - смерть".

Говоря про то, что видит в профайлере dba, если не используются хп, я имею ввиду кашу из кучи элементарных операций, которые трудно созерцаемы и тяжелы для анализа.(Прошу прощения если я не был достаточно конкретен).
Если говорить о предлагаемом варианте транслятора, то я не считаю такой вариант оправданным по ряду причин:
- вводится достаточно рискованный компонент в систему.
- искуственно вводятся дополнительные требования к специалистам для поддержки и разработки кода для этого транслятора, а также языковой семантики и т.п.
- PL/SQL, T-SQL не стоят на месте и постоянно развиваются. Различные шаблоны удобнее делать тем или иным методом в PL/SQL или T-SQL и довольно трудно выделить, и уж тем более придумать абстрактный аналог семантического написания некоторого блока кода на языке транслятора.

Так как я считаю, что CRUD по своей природе - это элементарный абстрактный API для доступа и манипуляции с объектами БД, менее затратным и рискованным будет подход именно генерации CRUD на основе модели и дополительных метаданных.
Лично использую PD и extended model definition + достаточно простые xslt-шаблоны.

Различным сложным расчетам и отчетам, наверное, не место в хп если требуется поддержка нескольких СУБД, хотя для каких то аналитических отчетов можно выработать определенный набор шаблонов которые будут манипулировать понятиями предметной области (OLAP-кубы, регистры, движениия/бизнес-транзакции...), и используя которые можно писать код на стороне сервера в некотором смысле абстрактно (шаблонно).