我正在为一个网站编写类似论坛的组件，它的用例非常类似于reddit或quora，其中包括主题，帖子，组等内容。我正在使用python和sqlalchemy核心，但仍然在争论我是否应该只使用ORM。我不想使用它的真正原因是避免另外一个组件处理事情，因为我被告知生成的查询可能会导致问题，随着事情的发展，你将不得不处理原始的sql以进行优化。
对于那些不使用ORM处理所有繁琐的CRUD和数据编组的人，我只是好奇，你是把它全部写出来还是做其他方法？你如何处理繁琐的数据编组？难道没有更好的方法来抓取结果对象并简单地执行以下操作：
result = user_dao.get_user(userid)
user.name = result.name
user.email = result.email
user.passwd = result.password_hash
[...]
对于某些对象/实体，当有15个以上的属性时，这会变得非常麻烦。
答案 0 :(得分：3)
有很多理由在运行selection / update / etc语句之外使用ORM。例如，它允许您将自定义功能绑定到应用程序中的记录，它可以防止SQL注入，它允许您更有效地移动到模型后面的新类类型，以及其他一些东西。
是的，在某些情况下，您可能需要为应用程序编写自定义SQL，但在ORM中使用连接功能，这实际上并不常见。我知道Perl的DBIx提供了“虚拟”类型，您可以在其中将自定义select语句投入到类中，并且仍然能够编写与该对象关联的方法。
将方法绑定到您选择的项目的能力可以改善代码的干扰。结合防止SQL注入导致我建议您尝试使用ORM，如果您有充分的理由，则不要使用ORM。你用来处理CRUD和数据编组的任何东西最终都会成为一个新的“ORM”，所以为什么不让其他人为你努力工作？
答案 1 :(得分：2)
这个问题似乎不值得所有的投票。我认为作者在这里有一个合理的担忧。
我亲自选择了ORM混合动力车。像SQL Alchemy这样的东西往往对我想要完成的事情有点过于沉重，并且它并不总能生成最有效的查询。我完全明白你为什么会犹豫不决。
从多个表中抓取字段时尤其如此。当我第一次开始使用SQL Alchemy时，我发现加入多个SELECT语句是一个艰难的决定。从那以后，我有点回避传统的ORM。
斯蒂芬施密特总体而言decent case反对ORM，但我认为这是一个幸福的中间立场。也许看看PyORMish？它真的很新，但经过了相当好的测试。它不是真正的ORM（因此是“ish”），但它减少了锅炉板代码，同时在需要时提供对原始SQL的简单访问。
免责声明：我是PyORMish的作者
答案 2 :(得分：2)
我怀疑下来的选票来自ORM粉丝男孩，我不是其中之一。我是一名专业软件工程师，并使用过多种ORM，尤其是NHibernate的。虽然ORM工具的创建是为了简化数据库编码工作的水平，在某些情况下，我发现自己在大型项目中遇到了重大问题。
如果我已经很好地了解数据库和SQL，为什么我要添加另一个第三方（我必须要学习所有关于它）之间必须以通用的方式工作并希望它能够以高效的方式工作有效的方法？如果不是，我必须搜索一些低音和低音的解决方案，以迫使它做我想做的事。
然后你甚至可以继续选择另一个ORM的其他项目，你也必须学习那个ORM的来龙去脉....... arg。
我的偏好是代码生成。像CodeSmith这样的东西是一个很好的工具，你可以学习一次并适用于几乎任何东西。您可以编写自己的高效代码，以一个表的CRUD的方式工作，然后将其转换为模板，在几秒钟内为100个表生成相同的CRUD。
我使用表定义启动我的应用程序，然后为CRUD sprocs运行我的模板，然后我有模板，使用直接ADO.Net创建DAL，使用这些sprocs，然后使用模板创建MVC模型，BAL，控制器和视图。巴姆！我有一个完整的数据库应用程序。然后我会针对最终结果定制事物。
我还设置了模板以使用“部分”类，因此我生成的大部分代码和自定义代码都是分开的，因此我可以随时重新生成代码，以便修改模板以修复问题或添加功能，等等。非常好添加一个功能，例如分页大型列表，并在几分钟到100秒的表内应用。
祝你好运。
答案 3 :(得分：1)
好吧，如果您使用ORM，则在优化时处理原始SQL。另一方面，如果没有ORM，您将在编写新代码，调试旧代码，测试功能和更改数据库方案时处理原始SQL。那是完全不同的。 ORM解决了很多事情。做一个男人并面对它：你不想学习另一种技术而你正在找借口。
许多ORM优化您的SQL，它们可以保护您免受许多攻击类型的攻击，它们代表了数据模型的新抽象级别。
相信我，你不想仅仅因为你重命名了一个列来搜索成千上万的旧的，硬编码的SQL查询......