В прогах, которые я пишу мне регулярно нужно сталкиваться с обращениями к базе данных. Порыскав по сети и почитав форумы (этот в частности), столкнулся с большим количеством рекомендаций использовать над базами слой абстракций типа Алхимии. Поизучав Алхимию, пришел к выводу, что мне очень не удобно конструировать запросы из ее классов, а куда приятнее запихать всю логику БД в хранимые функции и вызывать из кода только их. Но хотелось бы разобраться, с чем связано такое пристрастие питонистов к Алхимии. Возможно я что-то важное упустил из виду, и при усложнении проета придется столкнуться со значительными трудностями. Прошу Гуру не засерать эту тему как ламерскую, а постараться объяснить какие имеются плюсы и минусы использования sqlAlchemy. Заранее стасибо.

Я не использую ОРМ, т.к. лично для меня это не имеет смысла. Но в свое время исследовал этот вопрос и к такому решению пришел сознательно.

Преимущества использования любого ОРМ сводятся к 2 вещам:
1. Программирование только на Питоне, без SQL. Полезно для тех, кто не умеет работать с SQL.
2. Поддержка множества СУБД и реализация DB-API 2.0. Наверное, самое существенное преимущество. В теории один и тот же код может работать с разными СУБД. На практике могут быть редковстречаемые, но труднопреодолимые проблемы.

Недостатки описывать не буду. Раз уж вы задаете вопрос в таком ключе, значит понимаете о чем идет речь.

Вообще по моим представлениям ORM появились как средство упрощения обработки данных, получаемых от БД, в таких языках как C++. Там я думаю весьма удобно иметь слой абстракции, который преобразует данные в удобную для программиста форму. Но в питоне по моим понятиям все в порядке - в нем очень удобные встроенные типы данных, и стандартный средства обращений к БД замечательно их используют. Или я ошибаюсь?

Очень бы хотелось послушать сторонников использования Алхимии.

Может появилось ORM из этих соображений, но кроссбазовость и однообразие в программировании - главные преимущества ORM.

Честно говоря думал меня убедят, что ORM - великая вещь и надо ей пользоваться. Вышло все наоборот. Мне как-то удобнее пользоваться хранимыми процедурами - не надо изучать еще один здоровенный кусок англоязычной документации. Да и спрятать всю SQLную логику внутри самой БД это на мой взгляд очень правильно, и быстрее (уж чем питоновый код то уж точно) и безопаснее (в случае сетевых приложений), да и само по себе как-то более красиво.

Дело ваше.

Ardling Я отчего-то не понял почему вы противопоставляете сохраненки и ORM?
И какие ORM, реализованные на С++, вам известны???
Всегда считал, что ноги начали расти из Java Hibernate.

ORM - это не обязательно способ реализации бизнес-логики на стороне клиента.
В первую очередь это объектно-ориентированный интерфес к БД.

Думаю, вы в работе классы используете? Может, даже пишете в ООП стиле? И как, не жмет?
Ведь любую задачу можно решить функциональным способом!

Сохраненки - это тоже по большому счету паллиатив. Мне каждый раз при создании чего-то по настоящему большого приходилось делать трехуровневую архитектуру.
То есть развитие идет так: ORM->сохраненки->сервисы. Плюс кеширование.
Не забывайте еще и о скорости создания конечного продукта. Чем проще - тем быстрее.

О произвдительности говорить считаю неприличным до того, как были произведены замеры для конкретного случая.
Ибо скорость сферического коня в вакууме практически равна скорости света.

Ferroman
кроссбазовость и однообразие в программировании - главные преимущества ORM

Сейчас существует множество DACов, которые реализуют то же самое. Даже древний ADO этим обладает.
Возникает логичный вопрос, по сравнению с какой технологией у ОРМ эти 2 параметра являются преимуществами?

Lexander
О чём конкретно разговор? Мне эти аббривиатуры никак не вяжутся с сабжем.

DAC - Data Access Components - технология доступа к данным.
ADO - одна из надстроек над DAC производства Microsoft.