Какие есть хорошие решения Python ORM?
Я оцениваю и смотрю на использование CherryPy для проекта, который в основном представляет собой интерфейс JavaScript со стороны клиента (браузера), который взаимодействует с веб-службой Python на стороне клиента. Итак, мне действительно нужно что-то быстрое и легкое на бэкэнде, которое я могу реализовать с помощью Python, который затем обращается к базе данных PostgreSQL через ORM (JSON для браузера).
Я также смотрю на Django, который мне нравится, поскольку его ORM встроен. Однако я думаю, что Django может быть немного больше, чем мне действительно нужно (т.е. больше функций, чем мне действительно нужно == медленнее?).
У кого-нибудь есть опыт работы с различными решениями Python ORM, которые могут сравнивать и сравнивать их функции и функциональность, скорость, эффективность и т. д.?
Объектно-реляционное сопоставление (ORM) уже очень популярно во многих языках программирования и является одной из лучших альтернатив SQL. На создание CQL для моего проекта TRIADB меня вдохновил стиль цепочки методов. healis.eu/triadb/#latest-release
Ответы 12
Думаю, вы могли бы посмотреть:
Осень, вероятно, проще, чем Storm, но Storm включает в себя много функций, которых нет в Autumn. Документация по обоим этим параметрам ограничена, хотя Storm так быстро исправляет!
Спасибо, Autumn выглядит очень красиво и привлекательно, но без документации, что для меня является преградой.
Я просто попробовал некоторые из примеров на осенней странице, и они даже не работают с версией кода, установленным моим диспетчером пакетов. Посты в гугл группе тоже старые. Похоже, проект умирает медленной смертью. Не рекомендую его использовать.
С другой стороны, Storm быстро становится моим предпочтительным ORM. Документы становятся лучше, а API ясен и прост, хотя я немного больше привык к шаблону ActiveRecord, используемому в Django ORM, я считаю, что в Storm легко ориентироваться.
Похоже, что у Autum не было никакой активности в течение года. groups.google.com/group/autumn-orm
Я бы посмотрел SQLAlchemy
Его действительно легко использовать, и модели, с которыми вы работаете, совсем не плохие. Django использует SQLAlchemy для ORM, но его использование само по себе позволяет использовать его на полную мощность.
Вот небольшой пример создания и выбора объектов orm
>>> ed_user = User('ed', 'Ed Jones', 'edspassword')
>>> session.add(ed_user)
>>> our_user = session.query(User).filter_by(name='ed').first()
>>> our_user
<User('ed','Ed Jones', 'edspassword')>
Django использует нет sqlalchemy для ORM. Была проделана некоторая работа, чтобы сделать sqlalchemy необязательной ORM, но она не завершена.
SQLAlchemy более полнофункциональный и мощный (использует шаблон DataMapper). Django ORM имеет более чистый синтаксис и его легче писать (шаблон ActiveRecord). Насчет разницы в производительности не знаю.
SQLAlchemy также имеет декларативный слой, который скрывает некоторую сложность и придает ему синтаксис в стиле ActiveRecord, более похожий на Django ORM.
Я бы не стал беспокоиться о том, что Django «слишком тяжелый». Он достаточно развязан, чтобы вы могли использовать ORM, если хотите без необходимости импортировать остальное.
Тем не менее, если бы я уже использовал CherryPy для веб-слоя и просто нуждался в ORM, я бы, вероятно, выбрал SQLAlchemy.
Но если вам не нравится ORM Django и вы хотите использовать SA, например, вы теряете множество функций django, таких как admin. Не нарушитель сделки, а ободранное колено.
Верно, но не имеет отношения к вопросу, который просто касался выбора ORM для Python; не о автоматически сгенерированных интерфейсах администратора или других компонентах фреймворка.
Я бы сказал, что SQLAlchemy совсем не легковесен - хотя он может быть довольно быстрым. Я добавлю свой проект в микс, он называется peewee и общается с postgres. Совсем недавно добавлена поддержка запросов в стиле django! charlesleifer.com/docs/peewee
Вас также может заинтересовать pypi.python.org/pypi/quick_orm
Не используйте SQLAlchemy, если вы хотите писать в шаблоне ActiveRecord. Почему? Просто прочтите документ docs.sqlalchemy.org/en/rel_0_7/orm/query.html и расскажите мне, как установить order_by в порядке DESC. Да, декларативный слой SQLAlchemy имеет ужасную документацию.
Также обратите внимание, что Django ORM не поддерживает составные первичные ключи, а SQLAlchemy поддерживает его.
@yegle Меня смущает ваш комментарий. Я не понимаю логики. Как "трудно найти инструкции по ORDER BYDESC в документации" означает "плохой для шаблона активной записи"?
@ jpmc26 Поскольку SQLAlchemy имеет другой шаблон, не относящийся к ActiveRecord (недекларативный уровень), здесь docs.sqlalchemy.org/en/rel_0_7/core/schema.html, который более устойчив по сравнению с моим PoV и лучше, чем его декларативный шаблон. Но этот комментарий был опубликован более 1 года назад для SQLAlchemy версии 0.7, после этого я не часто использовал SQLAlchemy, так что используйте свое собственное суждение :-)
Я обычно использую SQLAlchemy. Это довольно мощный и, вероятно, самый зрелый ORM для Python.
Если вы планируете использовать CherryPy, вы также можете изучить дежавю, поскольку он написан Робертом Брюером (парнем, который в настоящее время является руководителем проекта CherryPy). Я лично не использовал его, но знаю некоторых людей, которым он нравится.
SQLObject немного проще в использовании ORM, чем SQLAlchemy, но он не такой мощный.
Лично я бы не стал использовать Django ORM, если не планировал писать весь проект на Django, но это только я.
SQLObject великолепен - простой в использовании, независимый от базы данных, и он действительно может создавать таблицы за вас! (Мне лень).
@Lucas - Как и SQLAlchemy ...
Насколько я помню, я просто хвалил SQLObject. Хотя это было давно ... :)
@Lucas - Я так и думал. Просто подумал, что запомню это. :-)
Мы используем Эликсир вместе с SQLAlchemy, и пока он нам нравится. Elixir помещает слой поверх SQLAlchemy, что делает его более похожим на части «паттерна ActiveRecord».
SQLAlchemy поддерживает ООП и функциональные стили из коробки, Elixir добавляет поверх него декларативный стиль программирования (в основном для объявлений моделей, но с возможностью расширения).
Невозможно представить, чтобы неиспользуемые функции в Django снижали производительность. Может пригодиться, если вы когда-нибудь решите масштабировать проект.
есть способ понятный
Буря имеет, пожалуй, самый простой API:
from storm.locals import *
class Foo:
__storm_table__ = 'foos'
id = Int(primary=True)
class Thing:
__storm_table__ = 'things'
id = Int(primary=True)
name = Unicode()
description = Unicode()
foo_id = Int()
foo = Reference(foo_id, Foo.id)
db = create_database('sqlite:')
store = Store(db)
foo = Foo()
store.add(foo)
thing = Thing()
thing.foo = foo
store.add(thing)
store.commit()
И это позволяет безболезненно перейти к необработанному SQL, когда вам нужно:
store.execute('UPDATE bars SET bar_name=? WHERE bar_id like ?', [])
store.commit()
Следует отметить, что на данный момент Storm поддерживает только MySQL и PostgreSQL. Тем не менее, поддержка Oracle находится в разработке.
Он также поддерживает SQLite, как следует из приведенного выше примера.
quick_orm так же прост, как Storm, и основан на SQLAlchemy, поэтому он также очень мощный: pypi.python.org/pypi/quick_orm. Отказ от ответственности: я являюсь автором quick_orm
Спасибо за пример. У меня был вопрос о Шторме и отношениях «многие к одному». Я следую инструкциям и помещаю ссылку в конец моего файла за пределами класса, а затем импортирую другой класс, а в другом классе я импортирую текущий класс, и это создает импорт Ciruclar, но я не знаю, как еще это сделать?
Буря не поддерживается. Я бы не стал использовать его для новых проектов.
Кроме того, похоже, что для Python 3 нет Storm
Расширение SQLAlchemy декларативный, которое становится стандартом в версии 0.5, предоставляет универсальный интерфейс, очень похожий на Django или Storm. Он также легко интегрируется с классами / таблицами, настроенными с использованием стиля datamapper:
Base = declarative_base()
class Foo(Base):
__tablename__ = 'foos'
id = Column(Integer, primary_key=True)
class Thing(Base):
__tablename__ = 'things'
id = Column(Integer, primary_key=True)
name = Column(Unicode)
description = Column(Unicode)
foo_id = Column(Integer, ForeignKey('foos.id'))
foo = relation(Foo)
engine = create_engine('sqlite://')
Base.metadata.create_all(engine) # issues DDL to create tables
session = sessionmaker(bind=engine)()
foo = Foo()
session.add(foo)
thing = Thing(name='thing1', description='some thing')
thing.foo = foo # also adds Thing to session
session.commit()
Но все становится очень сложным, если существует много отношений, таких как one_to_many, many_to_many, наследование таблиц. Вы должны написать много кода вручную, чтобы справиться с ними. Проверьте мой ответ на Quick ORM. Это может сэкономить ваше время.
:) когда Тайлер говорит создателю SQLAlchemy, что ему следует использовать Quick ORM.
:) Напоминает мне, как много лет назад кто-то на usenet спорил с dmr @ alice, что он действительно не понимает C.
@AnthonyBriggs, посмотрите этот слайд, и вы поймете, почему quick_orm лучше справляется со сложными отношениями, чем SQLAlchemy: slideshare.net/tyler4long/quickorm
SQLAlchemy очень и очень мощный. Однако он не является потокобезопасным, убедитесь, что вы помните об этом при работе с cherrypy в режиме пула потоков.
правда ли, что SQLAlchemy не является потокобезопасным? Тогда как он используется в приложениях Pyramid поверх WSGI, которые в основном люди развертывают в многопоточном режиме? Никаких подтверждений этому противоречивому утверждению.
Конечно, SQLAlchemy ориентирована на многопоточность.
Я использовал Storm + SQLite для небольшого проекта и был очень доволен им, пока не добавил многопроцессорность. Попытка использовать базу данных из нескольких процессов привела к исключению «База данных заблокирована». Я перешел на SQLAlchemy, и тот же код работал без проблем.
Честно говоря, SQLite не предназначен для одновременного доступа.
@Xion +1. SQLITE - это единственный файл без запущенного демона.
Кажется, это каноническая точка отсчета для высокоуровневого взаимодействия с базой данных в Python: http://wiki.python.org/moin/HigherLevelDatabaseProgramming
Отсюда похоже, что Дежавю довольно абстрактно реализует шаблон DataMapper Мартина Фаулера в Python.
Я заинтересовался и посмотрел на дежавю. Лишь малость. Документация очень скудная (цитата «для уровня представления вы сами по себе»), поэтому я бы сказал, только для опытных пользователей.
Если вы ищете легковесные и уже знакомы с декларативными моделями в стиле django, посмотрите peewee: https://github.com/coleifer/peewee
Пример:
import datetime
from peewee import *
class Blog(Model):
name = CharField()
class Entry(Model):
blog = ForeignKeyField(Blog)
title = CharField()
body = TextField()
pub_date = DateTimeField(default=datetime.datetime.now)
# query it like django
Entry.filter(blog__name='Some great blog')
# or programmatically for finer-grained control
Entry.select().join(Blog).where(Blog.name == 'Some awesome blog')
Проверьте документы для получения дополнительных примеров.