【问题标题】:Should I be using SQLObject, SQLAlchemy, or SQLAlchemy + Elixir?我应该使用 SQLObject、SQLAlchemy 还是 SQLAlchemy + Elixir?
【发布时间】:2011-05-03 06:45:03
【问题描述】:

我已经使用 SQLObject 很长时间了,但注意到 SQLAlchemy 在过去几年变得越来越流行:http://www.google.com/trends?q=sqlobject,+sqlalchemy

切换到 SQLAlchemy 是否有令人信服的理由?它相对于 SQLObject 的性能如何?它的可用性?使用 Elixir 会增加多少性能开销?

我的需求是基本的、简单的 CRUD。没有什么异国情调。

我见过this related question,但它是在 1 年前提出的,但没有太多回应。

【问题讨论】:

    标签: python sqlalchemy sqlobject python-elixir


    【解决方案1】:

    我在 TurboGears 0.9 中广泛使用了 SqlObject,但在 TurboGears 之前就改用 SqlAlchemy + elixir 作为 SqlObject 的替代品。

    请注意,即使没有 elixir,SqlAlchemy 也有它自己的声明式样式类定义: http://docs.sqlalchemy.org/en/rel_1_0/orm/extensions/declarative/index.html

    如果您不确定性能,在您的应用中放入 elixir 作为替代品并进行一些快速分析应该不会有太多工作量。我猜想 SqlObject/SQL/SQLA+elixir 之间的性能差异与向/从数据库写入和读取数据所花费的时间相比显得苍白无力。

    请注意,SqlAlchemy 可以更好地控制 relationshipscolumns 的急切/延迟加载,这在很多情况下有助于您的应用程序的内存占用和性能。

    可能最令人信服的切换原因是 SqlAlchemy 正在积极开发中(尽管我对 SqlObject 的开发状态不再了解太多)。 作为次要原因,您可以放心,如果您的需求变得更复杂,很可能有其他人已经尝试使用 SqlAlchemy 成功地将 Python 对象的方钉插入 SQL 的圆孔中。

    【讨论】:

      猜你喜欢
      • 1970-01-01
      • 2010-10-10
      • 2010-11-22
      • 2012-01-25
      • 2016-07-06
      • 1970-01-01
      • 2011-03-07
      • 2013-12-17
      • 1970-01-01
      相关资源
      最近更新 更多