korda
- Нет проблем с синтаксисом, - всегда генерируется синтаксически правильный запрос;


Синтаксически - да. Но если допустить ляп в метаданных, то он молча будет неправильным логически. А это отловить куда тяжелее.

korda
- Возможность рефакторинга (если мне нужно переименовать таблицу или поле, то я делаю это лишь в одном месте);


Чего-то я не понял. Ну, переименуйте Person в Man в следующем примере. Или Вы предлагаете оствить в тексте объект Person, и думаете, что это способствует удобочитаемости? По мне так лучше Search/Replace.


korda
А подсветка синтаксиса?


В FAR есть.

korda
А отлавливание синтаксических ошибок по мере набора?


Мне кажется, проверять ошибки имеет смысл, только когда запрос набран полностью. Набрали - нажали - проверили.

korda
А подсказки во время набора?


А Вы считате, что в классическом синтаксисе SQL это принципиально невозможно? СтОит ли городить объектную надстройку ради этого?

korda
А удобная работа по сравнению версий?


Ресурсные файлы с SQL-запросами лежат в CVS наравне с другими исходниками.

korda
А проверка орфографии в комментариях?


Если это так существенно, можно набирать запросы в MS Word. А "скрепка с глазами" пусть синтаксис подсказывает :-)

Я бы все же успокоился, и переформулировал задачу заново, чтобы ограничить область наших аппетитов. Например, так:

Проблема: при построении приложений заметное время приходится тратить на написание однообразных "типовых" SQL-запросов вида


Проблема заключается в том, что в тексте этих запросов в какой-то мере дублируется информация о структуре и связях таблиц в БД, так что при наращивании структуры, например, при добавлении полей в таблицы, особенно полей, ссылающихся на новые справочники, приходится дорабатывать значительную часть существующих запросов, причем дорабатывать чисто "механически".

Предлагается: создать генератор типовых SQL-запросов.

Требования: он должен брать информацию о структуре БД из некого репозитория метаданных (из системных таблиц БД, или каких-то промежуточных - на данном этапе неважно), и принимать аргументами только недостающую, "прикладную" информацию.

Например, есть есть таблицы man (полсотни полей, куча справочников), street и city, и требуется вывести имя человека с адресом, то в классическом случае мы пишем

Query1.SQL := '
SELECT street.name AS streetname, city.name AS cityname, man.housenum, man,apartnum, man.name AS manname
FROM man, street, city
WHERE man.street_id = street.id
AND street.city_id = city.id
AND man.id = :parameter';

А хочется написать как-то так:

Query1.SQL := SQLGenerator.Generate(
tablename => 'man',
fields_only => 'name, housenum, apartnum',
joins_only => 'street' // city по умолчанию подцепится само
where => "man.id = :parameter"
);

То есть, синтаксис аргументов генератора должен примерно соответствовать синтаксической конструкции ВЫБРАТЬ в начале сообщения, то есть поддерживать конструкции "все кроме" и т.д. Если продумать поведение по умолчанию, то можно значительно сократить объем текста для написания типового запроса, и облегчить, а то и вовсе исключить его модификацию при наращивании структуры БД.

Как уже говорили, автоматически названные поля могут быть довольно причудливыми. Поэтому напрашивается какая-то система автоматической привязки русских заголовков таким полям. Тогда неуклюжесть автоназваний останется внутри системы.

Вот в таком виде, как мне кажется, задача приобретает хоть какой-то полезный смысл. Главное - незачем дублировать метаданные в тексте программы.

kordaэлементы вычисляемых полей должны фигурироывть каждый, со своим алиасом, в то время, как эти алиасы генерируются автоматически и на момент описания мета-данных не известны

Чтобы они были известны, нужно отказаться от промелькнувшей ранее мысли генерировать их со сквозным порядковым номером, и вернуться к вопросу о разумном алгоритме наименования алиасов. Если он будет очевидным, то прикинуть его "в уме" и понять имена будущих алиасов будет несложно.
В крайнем случае, можно значала описать SQL-запрос, просмотреть его текст в каком-то отладочном режиме, и посмотреть, что там за алиасы. А потом уже добавить вычисляемые поля.

А вообще, еще раз говорю - задача достаточно сложная. Если главная проблема - сэкономить время сейчас, то лучше и не влезайте.