โซลูชั่น Python ORM ที่ดีคืออะไร [ปิด]


209

ฉันกำลังประเมินและมองหาการใช้ CherryPy สำหรับโครงการที่เป็นพื้นหน้า JavaScript จากฝั่งไคลเอ็นต์ (เบราว์เซอร์) ที่พูดคุยกับ Python เว็บเซอร์วิสด้านหลัง ดังนั้นฉันต้องการบางสิ่งที่รวดเร็วและมีน้ำหนักเบาที่ back-end ที่ฉันสามารถนำไปใช้โดยใช้ Python ที่พูดกับ PostgreSQL DB ผ่าน ORM (JSON กับเบราว์เซอร์)

ฉันกำลังดู Django ด้วยซึ่งฉันชอบเนื่องจาก ORM ของมันมีอยู่ในตัว อย่างไรก็ตามฉันคิดว่า Django อาจจะมากกว่าที่ฉันต้องการเล็กน้อย (เช่นมีฟีเจอร์มากกว่าที่ฉันต้องการ == ช้าลงไหม?)

ทุกคนมีประสบการณ์ใด ๆ กับโซลูชัน Python ORM ที่แตกต่างกันซึ่งสามารถเปรียบเทียบและเปรียบเทียบคุณลักษณะและฟังก์ชันการทำงานความเร็วประสิทธิภาพ ฯลฯ


ponyORMดูดีมาก
Niklas R

การทำแผนที่วัตถุเชิงสัมพันธ์ (ORM) เป็นที่นิยมมากในภาษาการเขียนโปรแกรมจำนวนมากและเป็นหนึ่งในทางเลือกที่ดีที่สุดสำหรับ SQL ฉันได้รับแรงบันดาลใจจากวิธีการผูกมัดแบบเพื่อสร้าง CQL สำหรับโครงการ TRIADB ของฉัน healis.eu/triadb/#latest-release
Athanassios

คำตอบ:


96

SQLAlchemy มีคุณสมบัติครบถ้วนและทรงพลังมากขึ้น (ใช้รูปแบบ DataMapper) Django ORM มีไวยากรณ์ที่สะอาดกว่าและเขียนได้ง่ายกว่า (รูปแบบ ActiveRecord) ฉันไม่รู้เกี่ยวกับความแตกต่างด้านประสิทธิภาพ

SQLAlchemy ยังมีชั้นประกาศที่ซ่อนความซับซ้อนบางอย่างและทำให้มันเป็นรูปแบบ ActiveRecord- รูปแบบคล้ายกับ Django ORM

ฉันไม่ต้องกังวลว่า Django จะ "หนักเกินไป" ก็พอที่ decoupled ที่คุณสามารถใช้ออมถ้าคุณต้องการได้โดยไม่ต้องนำเข้าส่วนที่เหลือ

ที่กล่าวว่าถ้าฉันใช้ CherryPy สำหรับเลเยอร์เว็บและต้องการ ORM ฉันก็อาจเลือกใช้ SQLAlchemy


7
แต่ถ้าคุณไม่ชอบ ORM ของ Django และต้องการใช้ SA คุณจะสูญเสียคุณสมบัติจำนวนมากของ django เช่นผู้ดูแลระบบ ไม่ใช่ตัวแบ่งข้อตกลง แต่เป็นหัวเข่าที่ถลกหนัง
Gregg Lind

22
จริง แต่ไม่เกี่ยวข้องกับคำถามซึ่งเป็นเรื่องเกี่ยวกับการเลือก Python ORM; ไม่เกี่ยวกับอินเตอร์เฟสผู้ดูแลระบบที่สร้างขึ้นโดยอัตโนมัติหรือส่วนประกอบเฟรมเวิร์กอื่น ๆ
Carl Meyer

8
ฉันจะยืนยันว่า SQLAlchemy เป็นอะไรก็ได้ แต่มีน้ำหนักเบา - มันสามารถทำได้ค่อนข้างเร็ว ฉันจะโยนโปรเจ็กต์ของฉันลงในมิกซ์เรียกว่าพีอีวีและมันก็พูดถึง postgres เพิ่งเพิ่มการสนับสนุนสำหรับการสอบถามสไตล์ django ด้วยเช่นกัน! charlesleifer.com/docs/peewee
coleifer

3
โปรดทราบว่า Django ORM ไม่สนับสนุนคีย์หลักผสมและ SQLAlchemy สนับสนุน
Marcin Kapusta

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')

ตรวจสอบเอกสารเพื่อดูตัวอย่างเพิ่มเติม


คุณสามารถช่วยฉันสำหรับคำถามนี้ได้ไหม กรุณา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 เป็นง่ายๆเป็นพายุและมันถูกสร้างขึ้นบน SQLAlchemy ดังนั้นจึงยังเป็นที่มีประสิทธิภาพมาก: pypi.python.org/pypi/quick_orm ข้อสงวนสิทธิ์: ฉันเป็นผู้เขียน quick_orm
Tyler Long

8
พายุไม่เคยถูกทำลาย ฉันจะไม่ใช้มันสำหรับโครงการใหม่
Matthias Urlichs

3
ดูเหมือนว่าไม่มี Storm สำหรับ Python 3
ygormutti

27

ผมมักจะใช้SQLAlchemy มันค่อนข้างทรงพลังและน่าจะเป็นงูหลาม ORM ที่โตที่สุด

หากคุณวางแผนที่จะใช้ CherryPy คุณอาจดูเป็นdejavuโดย Robert Brewer (คนที่เป็นผู้นำโครงการ CherryPy ในปัจจุบัน) ฉันไม่ได้ใช้มันเป็นการส่วนตัว แต่ฉันรู้จักบางคนที่รักมัน

SQLObjectนั้นใช้งาน ORM ได้ง่ายกว่า SQLAlchemy เล็กน้อย แต่ก็ไม่ค่อยมีประสิทธิภาพเท่าไหร่

โดยส่วนตัวแล้วฉันจะไม่ใช้ Django ORM ถ้าฉันไม่ได้วางแผนที่จะเขียนโครงการทั้งหมดใน Django แต่นั่นเป็นเพียงฉัน


SQLObject นั้นยอดเยี่ยม - ใช้งานง่ายไม่ต้องใช้ฐานข้อมูลและสามารถสร้างตารางให้คุณได้จริง! (ฉันขี้เกียจ).
ลูคัสโจนส์

1
@Lucas - SQLAlchemy สามารถ ...
Jason Baker

เท่าที่ฉันจำได้ฉันมักจะชื่นชม SQLObject นานมาแล้วแม้ว่า ... :)
ลูคัสโจนส์

@Lucas - ฉันคิดเช่นนี้ แค่คิดว่าฉันจะจดบันทึกมัน :-)
Jason Baker

17

ส่วนขยายที่ประกาศของ SQLAlchemy ซึ่งกำลังกลายเป็นมาตรฐานใน 0.5 จะให้ส่วนต่อประสานทั้งหมดในหนึ่งอินเทอร์เฟซเหมือนกับ Django หรือ Storm นอกจากนี้ยังผสานรวมเข้ากับคลาส / ตารางที่กำหนดค่าโดยใช้สไตล์ดาต้าแมป:

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
:) เตือนฉันถึงใครบางคนเมื่อหลายปีก่อนที่ usenet โต้เถียงกับ dmr @ alice ที่เขาไม่เข้าใจจริงๆ C.
Peter Rowell

@AnthonyBriggs ตรวจสอบสไลด์นี้แล้วคุณจะเห็นว่าทำไม quick_orm ถึงดีกว่าในการจัดการความสัมพันธ์ที่ซับซ้อนกว่า SQLAlchemy: slideshare.net/tyler4long/quickorm
Tyler Long

10

เราใช้Elixirควบคู่กับ SQLAlchemy และชอบมันมาก Elixir วางเลเยอร์ไว้ด้านบนของ SQLAlchemy ซึ่งทำให้ดูเหมือนส่วนเคาน์เตอร์ "รูปแบบ ActiveRecord"


2
SQLAlchemy รองรับ OOP และลักษณะการทำงานนอกกรอบ, Elixir เพิ่มสไตล์การเขียนโปรแกรมที่ประกาศ (ส่วนใหญ่สำหรับการประกาศแบบจำลอง แต่สามารถ exdended) ที่ด้านบนของมัน
muhuk

5

นี่น่าจะเป็นจุดอ้างอิงแบบบัญญัติสำหรับการโต้ตอบกับฐานข้อมูลระดับสูงใน Python: http://wiki.python.org/moin/HigherLevelDatabaseProgramming

ดูเหมือนว่าDejavu จะใช้รูปแบบ DataMapper ของ Martin Fowler ใน Python


ฉันสนใจและดู Dejavu เพียงเล็กน้อย. เอกสารนั้นกระจัดกระจายมาก (qoute "สำหรับเลเยอร์การนำเสนอที่คุณอยู่ด้วยตัวคุณเอง") ดังนั้นสำหรับผู้ใช้ขั้นสูงเท่านั้นที่ฉันจะพูด
r4

1

ฉันคิดว่าคุณอาจจะดู:

ฤดูใบไม้ร่วง

พายุ


Autumn อาจจะง่ายกว่า Storm แต่ Storm มีคุณสมบัติมากมายที่ Autumn ไม่ได้มี ตัวเลือกทั้งสองตัวนี้มีเอกสาร จำกัด แม้ว่า Storm กำลังแก้ไขอย่างรวดเร็ว!
alecwh

ขอบคุณฤดูใบไม้ร่วงดูดีและน่าสนใจมาก แต่ไม่มีเอกสารประกอบซึ่งเป็นตัวแบ่งข้อตกลงสำหรับฉัน
temoto

1
ฉันลองตัวอย่างบางส่วนในหน้า Autumn และพวกเขาไม่สามารถใช้งานได้กับเวอร์ชันของโค้ดที่ผู้จัดการแพ็คเกจของฉันติดตั้ง โพสต์ในกลุ่ม google ยังเก่า ดูเหมือนว่าโครงการกำลังจะตายอย่างช้าๆ ไม่แนะนำให้ใช้
Jason Miesionczek

พายุในอีกทางหนึ่งอย่างรวดเร็วกลายเป็นทางเลือกในการออมของฉัน เอกสารเริ่มดีขึ้นและ API นั้นสะอาดและเรียบง่าย แต่ฉันคุ้นเคยกับรูปแบบ ActiveRecord ที่ใช้โดย Django ORM มากขึ้นฉันพบว่า Storm ใช้งานง่าย
Jason Miesionczek

1
Autum ดูเหมือนจะไม่มีกิจกรรมใด ๆ เป็นเวลาหนึ่งปี groups.google.com/group/autumn-orm
Sridhar Ratnakumar

1

ไม่มีวิธีที่เป็นไปได้ที่คุณสมบัติที่ไม่ได้ใช้ใน Django จะให้โทษประสิทธิภาพ อาจมีประโยชน์ถ้าคุณตัดสินใจที่จะทำโปรเจค


8
มีconcievableวิธี
bukzor

0

ฉันใช้ Storm + SQLite สำหรับโครงการขนาดเล็กและมีความสุขมากกับมันจนกว่าฉันจะเพิ่มการประมวลผลหลายตัว กำลังพยายามใช้ฐานข้อมูลจากหลายกระบวนการทำให้เกิดข้อยกเว้น "ฐานข้อมูลถูกล็อก" ฉันเปลี่ยนเป็น SQLAlchemy และรหัสเดียวกันทำงานได้โดยไม่มีปัญหา


7
เพื่อความเป็นธรรม SQLite ไม่ได้ออกแบบมาเพื่อการเข้าถึงพร้อมกัน
Xiong Chiamiov

2
@Xion +1 SQLITE เป็นไฟล์เดียวเท่านั้นโดยที่ไม่มี daemon ทำงานอยู่
E-satis

-1

SQLAlchemy นั้นมีประสิทธิภาพมาก อย่างไรก็ตามมันไม่ปลอดภัยเธรดให้แน่ใจว่าคุณจำไว้เมื่อทำงานกับ cherrypy ในโหมดเธรดพูล


2
เป็นความจริงที่ SQLAlchemy ไม่ได้เป็น threadsafe หรือไม่ ถ้าอย่างนั้นจะใช้ในแอป Pyramid บน WSGI ซึ่งคนส่วนใหญ่ปรับใช้ในโหมดเธรดได้อย่างไร? การยืนยันใด ๆ ถึงข้อความที่ขัดแย้งนี้
Ravi Kumar

1
แน่นอนว่า SQLAlchemy นั้นปลอดภัยต่อเธรด
Matthias Urlichs

-7

ฉันจะตรวจสอบSQLAlchemy

มันใช้งานง่ายมากและรุ่นที่คุณทำงานด้วยก็ไม่เลวเลย Django ใช้ 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
Django ไม่ได้ใช้ sqlalchemy เพราะเป็น ORM มีงานบางอย่างที่ทำให้ sqlalchemy เป็น ORM เสริม แต่ยังไม่เสร็จสมบูรณ์
sherbang
โดยการใช้ไซต์ของเรา หมายความว่าคุณได้อ่านและทำความเข้าใจนโยบายคุกกี้และนโยบายความเป็นส่วนตัวของเราแล้ว
Licensed under cc by-sa 3.0 with attribution required.