用于 Python 的 iBATIS？
在我目前的工作中，我们通过 Java 使用 iBATIS 来 CRUD 我们的数据库。 我喜欢该工具的抽象品质，尤其是在使用遗留数据库时，因为它不会将自己的语法强加给您。
我正在寻找与此库类似的 Python ，因为该网站仅提供 Java/.NET/Ruby 版本。 如果不需要，我不想切换到 Jython。
是否还有其他类似于 Python 的 iBATIS 功能的项目？
At my current gig, we use iBATIS through Java to CRUD our databases. I like the abstract qualities of the tool, especially when working with legacy databases, as it doesn't impose its own syntax on you.
I'm looking for a Python analogue to this library, since the website only has Java/.NET/Ruby versions available. I don't want to have to switch to Jython if I don't need to.
Are there any other projects similar to iBATIS functionality out there for Python?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
iBatis 将 SQL DML（或 SQL 的定义）隔离在 XML 文件中。 它特别关注 SQL 和其他地方定义的某些对象模型之间的映射。
SQL Alchemy 可以做到这一点——但它并不是一个真正非常完整的解决方案。 与 iBatis 一样，您只能拥有 SQL 表定义以及表与 Python 类定义之间的映射。
更完整的是拥有一个类定义，它也是 SQL 数据库定义。 如果类定义生成 SQL 表 DDL 以及查询和处理 DML，那就更完整了。
我在 SQLAlchemy 和 Django ORM 之间摇摆不定。 SQLAlchemy 可以以类似于 iBatis 的方式使用。 但我更喜欢以对象设计为中心，并让工具集从对象派生 SQL 实现。
我将 SQLAlchemy 用于大型、批量、独立项目。 DB 加载、模式转换、DW 报告等效果很好。 在这些项目中，重点是数据的关系视图，而不是对象模型。 例如，生成的 SQL 可以移至 PL/SQL 存储过程中。
我将 Django 用于 Web 应用程序，利用其内置的 ORM 功能。 您可以通过一些工作将 Django ORM 与 Django 环境的其余部分隔离。 您可以提供全局设置< /a> 将您的应用程序绑定到特定数据库，而无需使用单独的设置模块。
Django 包含许多常见关系（外键、多对多、一对一），它可以管理这些关系的 SQL 实现。 它为附加数据库生成键和索引定义。
如果您的问题主要是面向对象的，并且使用数据库进行持久化，那么 Django 近乎透明的 ORM 层具有优势。
如果您的问题很大程度上与 SQL 处理中心相关，那么在 SQLAlchemy 中查看生成的 SQL 的能力具有优势。
iBatis sequesters the SQL DML (or the definitions of the SQL) in an XML file. It specifically focuses on the mapping between the SQL and some object model defined elsewhere.
SQL Alchemy can do this -- but it isn't really a very complete solution. Like iBatis, you can merely have SQL table definitions and a mapping between the tables and Python class definitions.
What's more complete is to have a class definition that is also the SQL database definition. If the class definition generates the SQL Table DDL as well as the query and processing DML, that's much more complete.
I flip-flop between SQLAlchemy and the Django ORM. SQLAlchemy can be used in an iBatis like manner. But I prefer to make the object design central and leave the SQL implementation be derived from the objects by the toolset.
I use SQLAlchemy for large, batch, stand-alone projects. DB Loads, schema conversions, DW reporting and the like work out well. In these projects, the focus is on the relational view of the data, not the object model. The SQL that's generated may be moved into PL/SQL stored procedures, for example.
I use Django for web applications, exploiting its built-in ORM capabilities. You can, with a little work, segregate the Django ORM from the rest of the Django environment. You can provide global settings to bind your app to a specific database without using a separate settings module.
Django includes a number of common relationships (Foreign Key, Many-to-Many, One-to-One) for which it can manage the SQL implementation. It generates key and index definitions for the attached database.
If your problem is largely object-oriented, with the database being used for persistence, then the nearly transparent ORM layer of Django has advantages.
If your problem is largely relational, with the SQL processing central, then the capability of seeing the generated SQL in SQLAlchemy has advantages.
也许 SQLAlchemy SQL 表达式支持是合适的。 请参阅文档。
Perhaps SQLAlchemy SQL Expression support is suitable. See the documentation.