Какие хорошие решения для Python ORM? [закрыто]

210

Я оцениваю и смотрю на использование CherryPy для проекта, который в основном является интерфейсом JavaScript со стороны клиента (браузера), который взаимодействует с веб-сервисом Python на стороне сервера. Итак, мне действительно нужно что-то быстрое и легковесное на сервере, которое я могу реализовать с помощью Python, который затем обращается к БД PostgreSQL через ORM (JSON для браузера).

Я также смотрю на Django, который мне нравится, так как его ORM встроен. Тем не менее, я думаю, что Django может быть немного больше, чем мне действительно нужно (т.е. больше возможностей, чем мне действительно нужно == медленнее?).

Кто-нибудь имеет опыт работы с различными решениями Python ORM, которые могут сравнивать и сравнивать их функции и функциональность, скорость, эффективность и т. Д.?

eLuke
источник
ПониОРМ выглядит довольно мило.
Никлас Р
Объектно-реляционное отображение (ORM) уже очень популярно во многих языках программирования и является одной из лучших альтернатив для SQL. Я был вдохновлен стилем цепочки методов для создания CQL для моего проекта TRIADB. healis.eu/triadb/#latest-release
Athanassios

Ответы:

96

SQLAlchemy является более полнофункциональным и мощным (использует шаблон DataMapper). Django ORM имеет более чистый синтаксис и его легче писать (шаблон ActiveRecord). Я не знаю о различиях в производительности.

SQLAlchemy также имеет декларативный слой, который скрывает некоторую сложность и придает ему синтаксис в стиле ActiveRecord, более похожий на Django ORM.

Я бы не беспокоился о том, что Джанго «слишком тяжелый». Он настолько разделен, что вы можете использовать ORM, если хотите, без необходимости импортировать остальное .

Тем не менее, если бы я уже использовал CherryPy для веб-слоя и просто нуждался в ORM, я бы, вероятно, выбрал SQLAlchemy.

Карл Мейер
источник
7
Но если вам не нравится ORM в Django и вы хотите использовать SA, например, вы потеряете много функций django, таких как admin. Не прерыватель сделки, а колено с кожей.
Грегг Линд
22
Верно, но не имеет отношения к вопросу, который был просто о выборе Python ORM; не об автоматически сгенерированных интерфейсах администратора или других компонентах инфраструктуры.
Карл Мейер
8
Я бы сказал, что SQLAlchemy совсем не легок - он может быть довольно быстрым. Я добавлю свой проект в микс, он называется peewee и разговаривает с postgres. Только недавно добавлена ​​поддержка запросов в стиле Django! charlesleifer.com/docs/peewee
coleifer
3
Также обратите внимание, что Django ORM не поддерживает составные первичные ключи, а SQLAlchemy поддерживает его.
Марчин Капуста,
1
@yegle Меня смущает ваш комментарий. Я не понимаю логику. Как «трудно найти инструкции ORDER BY DESCв документах» означает «плохо для активной схемы записи»?
jpmc26
108

Если вы ищете легкий и уже знакомы с декларативными моделями в стиле 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')

Проверьте документы для большего количества примеров.

coleifer
источник
Вы можете помочь мне в этом вопросе? Pls ru.stackoverflow.com/q/1114189/293323
Cookie
81

У Storm , пожалуй, самый простой 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 еще в разработке.
Джейсон Бейкер
15
Он также поддерживает SQLite, как показывает приведенный выше пример
shearichard
2
quick_orm так же прост, как Storm, и основан на SQLAlchemy, поэтому он также очень мощный: pypi.python.org/pypi/quick_orm . Отказ от ответственности: я автор quick_orm
Тайлер Лонг
8
Буря не поддерживается. Я бы не использовал его для новых проектов.
Матиас Урликс
3
Кроме того, похоже, что нет шторма для Python 3
ygormutti
27

Я обычно использую SQLAlchemy . Это довольно мощный и, вероятно, самый зрелый Python ORM.

Если вы планируете использовать CherryPy, вы также можете посмотреть на dejavu как это Роберт Брюер (парень, который в настоящее время является лидером проекта CherryPy). Лично я не использовал это, но я знаю некоторых людей, которые любят это.

SQLObject немного проще в использовании ORM, чем SQLAlchemy, но он не такой мощный.

Лично я бы не использовал Django ORM, если бы не планировал написать весь проект на Django, но это только я.

Джейсон Бейкер
источник
SQLObject великолепен - прост в использовании, не зависит от базы данных, и он действительно может создать таблицы для вас! (Мне лень).
Лукас Джонс
1
@Lucas - Так может SQLAlchemy ...
Джейсон Бейкер
Насколько я помню, я просто дополнял SQLObject. Это было давно, хотя ... :)
Лукас Джонс
@ Лукас - я так и понял. Просто подумал, что запишу это. :-)
Джейсон Бейкер
17

Декларативное расширение 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()
zzzeek
источник
Но все становится очень сложным, если существует много отношений, таких как one_to_many, many_to_many, наследование таблиц. Вы должны написать много кода вручную, чтобы справиться с ними. Проверьте мой ответ на Quick ORM. Это может сэкономить ваше время.
Тайлер Лонг
18
:) Тайлер говорит создателю SQLAlchemy, что он должен использовать Quick ORM.
Энтони Бриггс
5
:) Напоминает мне кого-то много лет назад, когда пользователь usenet спорил с dmr @ alice о том, что он на самом деле не понимал C.
Питер Роуэлл,
@AnthonyBriggs, посмотрите этот слайд, и вы поймете, почему quick_orm лучше справляется со сложными отношениями, чем SQLAlchemy: slideshare.net/tyler4long/quickorm
Тайлер Лонг,
10

Мы используем Elixir вместе с SQLAlchemy и нам это до сих пор нравилось. Elixir помещает слой поверх SQLAlchemy, который делает его более похожим на элементы счетчика «шаблон ActiveRecord».

airportyh
источник
2
SQLAlchemy поддерживает ООП и функциональные стили из коробки, Elixir добавляет декларативный стиль программирования (в основном для объявлений моделей, но может быть расширен) поверх него.
Мухук
5

Кажется, это каноническая точка отсчета для взаимодействия с базами данных высокого уровня в Python: http://wiki.python.org/moin/HigherLevelDatabaseProgramming

Оттуда, похоже, Dejavu довольно абстрактно реализует шаблон DataMapper Мартина Фаулера в Python.

entropo
источник
Я заинтересовался и посмотрел на Дежавю. Лишь малость. Документация очень скудная (qoute "для уровня презентации, который вы сами по себе"), поэтому я бы сказал, только для опытных пользователей.
р4.
1

Я думаю, что вы можете посмотреть на:

осень

Буря

Лукас Шалкаускас
источник
Осень, вероятно, легче, чем Storm, но Storm включает в себя множество функций, которых нет у осень. Обе эти опции имеют ограниченную документацию, хотя Storm исправляет это быстро!
alecwh
Спасибо, осень выглядит очень красиво и привлекательно, но у нее нет документации, что для меня является нарушением условий сделки.
Темото
1
Я только что попробовал некоторые примеры на странице «Осень», и они даже не работают с версией кода, установленного моим менеджером пакетов. Сообщения в группе Google также старые. Похоже, проект умирает медленной смертью. Не рекомендовал бы использовать это.
Джейсон Месьончек
Шторм, с другой стороны, быстро становится моим ORM выбора. Документы становятся лучше, а API прост и понятен, хотя я немного больше привык к шаблону ActiveRecord, используемому в Django ORM, и считаю, что в Storm легко ориентироваться.
Джейсон Месьончек
1
Autum, кажется, не имеет никакой активности в течение года. groups.google.com/group/autumn-orm
Шридхар Ратнакумар
1

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

Карл Мейер
источник
8
есть разумный путь
букзор
0

Я использовал Storm + SQLite для небольшого проекта и был доволен им до тех пор, пока не добавил многопроцессорность. Попытка использовать базу данных из нескольких процессов привела к исключению «База данных заблокирована». Я перешел на SQLAlchemy, и тот же код работал без проблем.

Фил Лоден
источник
7
Если честно, SQLite не предназначен для одновременного доступа.
Сюн Чиамов
2
@Xion +1. SQLITE - это единственный файл, без запуска демона.
E-удовлетворительно
-1

SQLAlchemy очень, очень мощный. Однако это не безопасно для потоков, убедитесь, что имейте это в виду при работе с cherrypy в режиме пула потоков.

скоро
источник
2
правда ли, что SQLAlchemy не является потокобезопасным? Тогда как он используется в приложениях Pyramid поверх WSGI, которые в основном люди развертывают в многопоточном режиме? Любое подтверждение этому противоречивому утверждению.
Рави Кумар
1
Конечно, SQLAlchemy является поточно-ориентированным.
Матиас Урликс
-7

Я бы проверил 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')>
вон там
источник
18
Django не использует sqlalchemy для своего ORM. Была проделана определенная работа, чтобы сделать sqlalchemy необязательным ORM, но он еще не завершен.
Шербанг