Просто скажите что вам не интересно изучать SQL но хочется работать с БД.

Используя орм вы заранее отказываетесь от плюшек БД. Каких-то специальных конструкций и т.п.
К примеру преславутый entity framework для .Net не умеет использовать рекурсивные cte в mssql. И тогда начинается солянка, часть в функциях, часть в хп, часть в клиентском коде.

Может в каком нибудь проекте уровня "Мне тут программка надо накладные считать", сказал Вася Иванов владелец ларька и у него из БД только Access и тот ломаный, может и покатит. Тем более если другой владелец ларька Петя Петров имеет только Excel, такой же ломаный, тоже хочет такую программку.

Я бы сказал, что в Delphi ORM не распространены. Большинство толковых разработчков Delphi хорошо владеют SQL чтобы писать быстрые запросы.

Наши разработчики использующие C/AL и .Net (в обоих свои ОРМ) понятия не имеют как работает MSSQL и постоянно у них в воздухе висит вопрос, а почему на 3-ех терабайтной БД все тупит и тормозит и иногда возникают неожиданные артефакты в данных (непонимание изолированности транзакций) и то, что с данными в SQL надо работать как с множеством, и не итеративно. Там действует совершенно другая алгебра. В то время как службы написанные Delphi разработчиками работают уже лет 5 и никто не вспоминает про них, хотя они также активно работают с БД.

Но если вы твердо уверенны в использовании какой-нибудь ОРМ в своем проекте, то посмотрите в сторону DevArt. У них сильные компоненты работы с БД. Я думаю и EntityDAC тоже будет хороша.

Бьютиферkdv,

Простой пример: большая система. поменяли структуру базы.
Вопрос: как узнать, что все запросы остались рабочими без ОРМ?

Ответ без ОРМ: ???
Ответ с ОРМ: проект достаточно просто перекомпилировать.
Вы что-то путаете.Если меняют структуру БД, то в этом случае надо заново перемапливать объекты, а где гарантия что отношение объектов останется прежним или орм построит верные запросы.
Если вы про замену БД, то это надуманная проблема. Ни разу не видел, чтобы вбуханные миллионы в сервера, ПО, так легко меняли к примеру с mssql на oracle.

Товарищ старшинаX-Citeпропущено...

Вы что-то путаете.Если меняют структуру БД, то в этом случае надо заново перемапливать объекты, а где гарантия что отношение объектов останется прежним или орм построит верные запросы.
Если вы про замену БД, то это надуманная проблема. Ни разу не видел, чтобы вбуханные миллионы в сервера, ПО, так легко меняли к примеру с mssql на oracle.

Имхо, речь - об изменении объектной бизнес - модели. На основе измененной бизнес-модели ОРМ генерирует DDL - скрипт, модифицирующий структуру базы.
Именно в таком порядке. Хотя, слышал, что есть ORM "наоборот" - генерирует объектную модель на основе структуры базы. Но речь, имхо, не о реверс-генерации.
Если речь о БД только как о хранилище данных, то да, конечно, орм как нельзя кстати подходит: написал, сдал, забыл. Вот только использовать бд уровня mssql или oracle как хранилища, не используя их возможности. это кощунство.
P.S. моя сфера БД исключительно промышленного уровня и мне тяжело мыслить на уровне приложений для домашних настолок. Возможно там использование орм окупит затраты на поддержку. потому что применять не осознанные DDL скрипты, где только одна таблица может весить 200 Гб печально.
Один из примеров моей практики, ребята из .Net команды запустили некое обновление БД (тестовое) переводящее ее из состояния А в Б. При этом сделали это через ORM, т.к. их знаний SQL хватало только на select from. На все ушло около 2 часов. update delete alter и т.п. Проблема стала в том, что окно на обновление исключительно не более 15 минут. После чего, я потратив 30 минут на изучение что надо изменить и получить, написал за 10 минут скрипт, который перевел БД из состояния А в Б за 1 минуту. Теория множеств победила Теорию итераций.
Беда в том, что современные кодеры, совершенно не понимают как работает это там внутри.
Одно время я даже пробовал сам написать ормку заточенную под mssql, но когда дошел до оконных функций с кадрированием - сдался.

schiПытались в свое время использовать ORM от DevExpress (не на Delphi, правда). Остались стойкие отрицательные впечатления, потому что автоматически сгенерированные запросы были, мягко говоря, неоптимальны.
Тоже могу сказать и про entity :) проценку всеравно сделали в ХП, ну не может орм сгенерировать запрос к 1 тб за 400 мс и проценить 250 позиций

Автор же спрашивает имеет ли смысл начинать новый проект с ОРМ и если да, то какой.

Ответ: Имеет, если приложение останется на любительском уровне и не будет требовать высоких мощностей. Если из приложения планируется развить мощную высокопроизводительную ERP, то не имеет.