【发布时间】：2010-06-01 03:49:11
【问题描述】：
我应该投入大量时间来尝试找出 ORM 样式的实现，还是在 python/pylons/sqlalchemy 中坚持使用标准 SQL 查询仍然很常见？
【问题讨论】：
标签： python sql orm sqlalchemy
【发布时间】：2010-06-01 03:49:11
【问题描述】：
ORM 非常流行，有几个原因——例如：有些人宁愿不学习 SQL，ORM 可以简化不同 SQL 方言之间的移植，它们可能更适合大多数 OOP 风格的应用程序，甚至可能简化对非-SQL 实现的一些移植（例如，如果存储访问层依赖于 SQL 语句，那么将 Django 应用程序迁移到 Google App Engine 会工作得更多——因为它依赖于 ORM，即减少了一点所需的移植工作）。
SQLAlchemy 是我所知道的用于 Python 的最强大的 ORM —— 它可以让您在多个可能的级别上工作，从非常抽象的声明性级别一直到在您的分析工作确定的某些查询中注入实际 SQL一个很大的区别（我认为大多数人主要在中间级别使用它，它基本上在 OOP 和关系样式之间进行调解，就像其他 ORM 一样）。
在这件事上你没有征求我的个人意见，这与我上面总结的流行观点有点不合——我从来没有真正喜欢过任何类型的“代码生成器”（它们可以提高你的工作效率）一切都很顺利...但是当您发现自己调试问题 [[包括性能瓶颈]] 由于问题发生在生成器努力提供的抽象级别以下时，您可以有兴趣地偿还。
当我有机会使用 良好 关系引擎（例如 PostgreSQL）时，我相信我总体上比使用任何 ORM（包括 SQLAlchemy，尽管它有很多令人钦佩的品质）。但是，我不得不承认，当关系引擎不是那么好（例如，我从来没有喜欢 MySQL），或者移植到非关系部署是一个重要的考虑因素时，情况就不同了.
所以，回到你的实际问题，我确实认为，总的来说，花时间来掌握 SQLAlchemy 是一个好主意，而且时间花得很好。
【讨论】：
如果您以前从未使用过像 SqlAlchemy 这样的 ORM，我建议您学习它 - 只要您正在学习 Python 方式。如果不出意外，与普通 SQL 相比，您将能够更好地决定在何处/何时使用它。我认为您不应该为此投入大量时间。 SQLAlchemy 的文档很不错，如果遇到困难，您可以随时寻求帮助。
【讨论】：