좋은 파이썬 ORM 솔루션은 무엇입니까? [닫은]


209

저는 기본적으로 백엔드의 Python 웹 서비스와 통신하는 클라이언트 측 (브라우저)의 JavaScript 프론트 엔드 프로젝트에 CherryPy를 사용하고 평가하고 있습니다. 따라서 백엔드에는 Python을 사용하여 구현 한 다음 ORM (JSON은 브라우저로)을 통해 PostgreSQL DB와 통신 할 수있는 빠르고 가벼운 것이 필요합니다.

ORM이 내장되어 있기 때문에 내가 좋아하는 Django 도보 고 있습니다. 그러나 Django가 실제로 필요한 것보다 조금 더 많을 수 있다고 생각합니다 (즉, 실제로 필요한 것보다 더 많은 기능 == 느림).

누구나 다른 Python ORM 솔루션에 대한 경험이 있으십니까? 기능과 속도, 효율성 등을 비교하고 대조 할 수 있습니까?


ponyORM 은 꽤 좋아 보인다.
Niklas R

ORM (Object-Relational Mapping)은 이미 많은 프로그래밍 언어에서 널리 사용되며 SQL을위한 최상의 대안 중 하나입니다. TRIADB 프로젝트를위한 CQL을 생성하는 메소드 체인 스타일에서 영감을 받았습니다. healis.eu/triadb/#latest-release
Athanassios

답변:


96

SQLAlchemy는 기능이 더 강력하고 강력합니다 (DataMapper 패턴 사용). Django ORM은 구문이 더 깔끔하고 (ActiveRecord 패턴)을 작성하기가 더 쉽습니다. 성능 차이에 대해 모르겠습니다.

SQLAlchemy는 또한 약간의 복잡성을 숨기고 Django ORM과 더 유사한 ActiveRecord 스타일의 구문을 제공 하는 선언적 계층 을 가지고 있습니다.

Django가 "너무 무겁다"고 걱정하지 않습니다. 나머지를 가져 오지 않고 원하는 경우 ORM을 사용할 수있을 정도로 분리되었습니다 .

즉, 웹 계층에 이미 CherryPy를 사용하고 있고 ORM이 필요한 경우 SQLAlchemy를 선택했을 것입니다.


7
그러나 Django의 ORM이 마음에 들지 않고 SA를 사용하려는 경우 관리자와 같은 많은 장고 기능이 손실됩니다. 거래 차단기는 아니지만 피부가 벗겨진 무릎.
Gregg Lind

22
사실, 그러나 파이썬 ORM을 선택하는 것에 관한 질문과 관련이 없습니다. 자동 생성 된 관리 인터페이스 또는 기타 프레임 워크 구성 요소에 관한 것이 아닙니다.
Carl Meyer

8
나는 SQLAlchemy가 가벼운 것이 아니라고 주장한다. 그러나 그것은 매우 빠를 수있다. 나는 내 프로젝트를 믹스로 던질 것이고, peewee라고 불리우며 postgres와 대화합니다. 최근에 장고 스타일 쿼리에 대한 지원도 추가되었습니다! charlesleifer.com/docs/peewee
coleifer

3
Django ORM은 복합 기본 키를 지원하지 않으며 SQLAlchemy는이를 지원합니다.
Marcin Kapusta

1
@yegle 귀하의 의견에 혼란 스럽습니다. 나는 논리를 이해하지 못한다. " ORDER BY DESC문서에서 지시 사항을 찾기 어렵다"는 " 활성 레코드 패턴에 대한 불량"을 어떻게 의미합니까?
jpmc26

108

경량을 찾고 있으며 장고 스타일 선언 모델에 이미 익숙한 경우 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')

더 많은 예제 는 문서 를 확인하십시오 .


이 질문에 나를 도와 줄 수 있습니까? Pls ru.stackoverflow.com/q/1114189/293323
쿠키

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 만 지원합니다. 오라클 지원은 아직 진행 중이다.
Jason Baker

15
위의 예에서 알 수 있듯이 그것은 또한 SQLite도 지원
shearichard

2
quick_orm 스톰 한 간단하고 그것은 또한 매우 강력 그래서 SQLAlchemy의 기반으로 구축되어 pypi.python.org/pypi/quick_orm를 . 면책 조항 : 저는 quick_orm의 저자입니다
Tyler Long

8
폭풍은 유지되지 않습니다. 새 프로젝트에는 사용하지 않습니다.
Matthias Urlichs

3
또한 Python 3에 대한 폭풍이없는 것 같습니다
ygormutti

27

나는 보통 SQLAlchemy 사용 합니다. 꽤 강력하고 아마도 가장 성숙한 파이썬 ORM 일 것입니다.

CherryPy를 사용하려는 경우 Robert Brewer (현재 CherryPy 프로젝트 리더 인 사람)가 dejavu 를 살펴볼 수도 있습니다 . 나는 개인적으로 그것을 사용하지 않았지만 그것을 좋아하는 사람들을 알고 있습니다.

SQLObject 는 SQLAlchemy보다 ORM을 사용하는 것이 약간 쉽지만 강력하지는 않습니다.

개인적으로, Django에서 전체 프로젝트를 작성할 계획이 아니라면 Django ORM을 사용하지 않을 것입니다.


SQLObject는 사용하기 쉽고 데이터베이스와 무관하며 실제로 테이블을 만들 수 있습니다! (내가 게으른).
Lucas Jones

1
@Lucas-SQLAlchemy도 가능합니다 ...
Jason Baker

내가 기억할 수있는 한, 나는 일반적으로 SQLObject를 보완하고 있었다. 오래 전 일이지만 ... :)
Lucas Jones

@Lucas-나는 그렇게 생각했다. 내가 메모 할 것이라고 생각했습니다. :-)
Jason Baker

17

0.5로 표준이 된 SQLAlchemy의 선언적 확장 기능은 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에 대한 답변을 확인하십시오. 시간을 절약 할 수 있습니다.
Tyler Long

18
:) Tyler가 SQLAlchemy 제작자에게 Quick ORM을 사용해야한다고 말합니다.
Anthony Briggs

5
:) dmr @ alice와의 유즈넷 논쟁에서 몇 년 전 누군가가 C를 실제로 이해하지 못했다고 생각 나게합니다.
Peter Rowell

@AnthonyBriggs이 슬라이드를 확인하고 quick_orm이 SQLAlchemy의보다 복잡한 관계를 처리하는 더 나은 이유를 알 것 slideshare.net/tyler4long/quickorm
타일러 롱

10

우리는 SQLAlchemy와 함께 Elixir를 사용 했으며 지금까지 그것을 좋아했습니다. Elixir는 SQLAlchemy 위에 레이어를 배치하여 "ActiveRecord 패턴"카운터 파트처럼 보이게합니다.


2
SQLAlchemy는 기본적으로 OOP 및 기능적 스타일을 지원하며, Elixir는 선언적 프로그래밍 스타일을 추가합니다 (주로 모델 선언의 경우 확장 가능).
muhuk

5

이것은 파이썬에서 높은 수준의 데이터베이스 상호 작용을위한 표준 참조 지점 인 것 같습니다 : http://wiki.python.org/moin/HigherLevelDatabaseProgramming

거기에서 Dejavu 는 Martin Fowler의 DataMapper 패턴을 파이썬에서 상당히 추상적으로 구현 하는 것처럼 보입니다 .


나는 데자뷰에 관심이 있었고 보았다. 만 조금. 문서는 매우 드문 경우 (qoute "프레젠테이션 레이어의 경우 사용자가 직접 사용함") 고급 사용자에게만 해당됩니다.
r4.

1

나는 당신이 볼 수도 있다고 생각합니다 :

가을

폭풍


가을은 Storm보다 쉬울 수 있지만 Storm에는 가을에는없는 많은 기능이 포함되어 있습니다. Storm이 빠른 속도로 수정하고 있지만이 두 옵션 모두 문서가 제한되어 있습니다!
alecwh

감사합니다. 가을은 매우 멋지고 매력적이지만 문서가 없으므로 제게 거래 차단기입니다.
temoto

1
방금 가을 페이지에서 일부 예제를 시도했지만 패키지 관리자가 설치 한 코드 버전으로도 작동하지 않습니다. Google 그룹의 게시물도 오래되었습니다. 프로젝트가 느린 죽음으로 죽어가는 것 같습니다. 사용하지 않는 것이 좋습니다.
Jason Miesionczek

반면에 폭풍은 빠르게 내가 선택한 ORM이되었습니다. 문서가 나아지고 API는 깨끗하고 단순하지만 장고 ORM에서 사용하는 ActiveRecord 패턴에 조금 더 익숙하지만 Storm을 쉽게 탐색 할 수 있습니다.
Jason Miesionczek

1
Autum은 1 년 동안 활동이없는 것 같습니다. groups.google.com/group/autumn-orm
Sridhar Ratnakumar

1

Django에서 사용하지 않는 기능으로 인해 성능이 저하 될 수있는 방법은 없습니다. 프로젝트를 업 스케일하기로 결정한 경우 유용 할 수 있습니다.


8
거기입니다 concievable 방법
bukzor

0

소규모 프로젝트에 Storm + SQLite를 사용했으며 멀티 프로세싱을 추가 할 때까지 매우 기뻤습니다. 여러 프로세스에서 데이터베이스를 사용하려고하면 "데이터베이스가 잠겨 있습니다"예외가 발생했습니다. SQLAlchemy로 전환했으며 동일한 코드가 아무런 문제없이 작동했습니다.


7
공평하게 말하면 SQLite는 실제로 동시 액세스를 위해 설계되지 않았습니다.
Xiong Chiamiov

2
@ 시온 +1. SQLITE는 데몬이 실행되지 않는 유일한 파일입니다.
전자 위성

-1

SQLAlchemy는 매우 강력합니다. 그러나 스레드 안전하지는 않습니다. 스레드 풀 모드에서 cherrypy를 사용할 때 명심하십시오.


2
SQLAlchemy가 스레드 안전하지 않다는 것이 사실입니까? 그렇다면 사람들이 주로 스레드 모드로 배포하는 WSGI의 피라미드 앱에서 어떻게 사용됩니까? 이 모순 된 진술에 대한 확인.
라비 쿠마

1
물론 SQLAlchemy는 스레드로부터 안전합니다.
Matthias Urlichs

-7

SQLAlchemy를 확인했습니다.

사용하기가 쉽고 작업하는 모델이 전혀 나쁘지 않습니다. Django는 ORM에 대해 SQLAlchemy를 사용 하지만 자체적으로 사용하면 전체 기능을 사용할 수 있습니다.

다음은 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
장고는 ORM이기 때문에 sqlalchemy를 사용 하지 않습니다 . sqlalchemy를 선택적 ORM으로 만들기 위해 수행 된 작업이 있지만 완료되지 않았습니다.
sherbang
당사 사이트를 사용함과 동시에 당사의 쿠키 정책개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.