Найти - Пользователи
Полная версия: Для чего нужен sqlAlchemy?
Начало » Python для новичков » Для чего нужен sqlAlchemy?
1 2
Ferroman
А, я уже забыл о таких.
Победили реализации, а не сама технология. Да и поприетарность сыграла свою роль, я думаю.
regall
Как вспомню эти дата адаптеры в C# аж дрожь берет …
Ardling
Андрей Светлов
Я отчего-то не понял почему вы противопоставляете сохраненки и ORM?
И какие ORM, реализованные на С++, вам известны???
Всегда считал, что ноги начали расти из Java Hibernate.
Тут вы попали в точку - никогда ни чем подобным на сях не пользовался. Посему могу и заблуждаться, но соль вопроса моего не в этом, а в целесообразности подобных решений именно при работе с питоном.
Андрей Светлов
ORM - это не обязательно способ реализации бизнес-логики на стороне клиента.
В первую очередь это объектно-ориентированный интерфес к БД.
Да, я понимаю. Когда я писал на php, то очень удобно было работать с объектами, а не с массивами, которые возвращал стандартный интерфейс, да и в объектном воплощении работа с базой данных мне виделась более красивой. Но в питоне стандартная схема работы с БД показалась мне замечательной, и я не совсем понимаю зачем ее прятать за еще один слой абстракции. Потому и задал свой вопрос. Возможно есть примеры задач, где дополнительный слой упрощает логику, но я таких примеров не знаю. Если вы знаете, то приведите, если вамм не трудно.
Андрей Светлов
Думаю, вы в работе классы используете? Может, даже пишете в ООП стиле? И как, не жмет?
Ведь любую задачу можно решить функциональным способом!
Да можно. Я для вычислительных целей стараюсь использовать чистый С - получаются очень простые и быстрые программы(библиотеки). В питоне - по мере надобности. Пока в основном для рисования GUI на PyQt. У вас есть доводы против такого подхода?
Андрей Светлов
Сохраненки - это тоже по большому счету паллиатив. Мне каждый раз при создании чего-то по настоящему большого приходилось делать трехуровневую архитектуру.
То есть развитие идет так: ORM->сохраненки->сервисы. Плюс кеширование.
Не забывайте еще и о скорости создания конечного продукта. Чем проще - тем быстрее.
Просто мне показалось, что проще написать свои запросы в SQL чем возиться с объектами.
Андрей Светлов
О произвдительности говорить считаю неприличным до того, как были произведены замеры для конкретного случая.
Ибо скорость сферического коня в вакууме практически равна скорости света.
Ну можно рассмотреть конкретный случай, когда есть 2 реализации:
1) Запрос генерируется ORM на питоне, а затем передается в базу данных;
2) Заранее написанный запрос сразу передается в базу данных.
По моему ясно видно, что первый запрос будет выполняться дольше ровно на время, пока питон генерирует запрос.

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

PS Спасибо за развернутый ответ).
Lexander
Ardling
Еще раз говорю, что пока не сталкивался с необходимостью генерировать запросы на лету, если вы сталкивались, то поделитесь примерами, мне будет очень интересно.
Простой пример: когда количеств параметров запроса заранее не известно, т.е. пользователь имеет в своем распоряжении конструктор отчета.
В зависимости от выбранных настроек в окне задания параметров отчета будет сгенерирован один из отчетов:
select * from some_table where firm_id=1

select * from some_table where firm_id=1 and date between '20090101 01:01:01' and '20100101 01:01:01'

select * from some_table where firm_id=1 and contractor_id=2

select * from some_table a left join contractor c on c.contractor_id=a.contractor_id where firm_id=1 and c.contractor_type_id=2
Ardling
Спасибо, мне кажется я понял вашу мысль. Я все равно думаю что мне удобнее будет написать процедуру для каждого случая, но думаю в более сложной задаче можно получить выигрыш во времени разработки.
Андрей Светлов
Ardlingdbapi тоже не идеал, а временами хочется нормальных объектов. Чтобы можно было завести свой метод. Например, есть ли у user право на permission (требует доступа к нескольким - зависит от используемой модели прав - таблицам, учета квот и т.д.). Можно ложить этот код “снаружи” - но мне удобней встраивать его в класс User, который берется из БД. Вопрос удобства - очень личная вещь. То же самое относится к генерации запросов.

По поводу “что быстрее”: тормоза возникают не на создании запроса, а на пересылке ответа. Сохраненка может уменьшить количество передаваемых данных, отрабатывая в контексте database сервера.

P.S. Вы “чистый С” используете как C extensions для Питона? Как по мне - не самый удобный способ. Очень легко допустить ошибку (забыть вызвать decref, например) - а потом долго ее ловить. И повезло, если проявляется сразу.
This is a "lo-fi" version of our main content. To view the full version with more information, formatting and images, please click here.
Powered by DjangoBB