2016-04-25 29 views
-1

我有一个非常简单的问题。我打算做一个烧瓶应用程序,最终可能会产生一些复杂的SQL查询。出于这个原因,我决定不使用ORM,而且我更喜欢编写自己的SQL。使用psycopg2调用函数而不是原始查询

我写了一些简单的SQL在postgres函数中读取/写入数据,然后使用psycopg2进行函数调用。我认为这种方法比编写原始SQL更好,因为它很容易维护。

有没有人知道采取这种方法的任何缺陷,或psycopg2特有的限制?谢谢。

回答

1

即使您的应用程序仅限于Postgres,ORM也可以帮助您很多。我必须在不同的操作系统中支持非常复杂的部署,并且我知道当需求发生变化时,ORM可以为您节省大量工作和痛苦。绝对有一些(小!)性能受到影响,但是当它非常重要时(大容量插入/更新,普通SQL等),您可以避免大部分慢速路径。

我将以SQLAlchemy为例,但大多数ORM将具有等同的功能。

  1. 你在普通的Python或与ORM写一些数据映射到对象(甚至是字典),在ORM有它如果要使用此功能,免费
  2. Define tables and models在您的代码中。你甚至不必使用SQLAlchemy对象。
  3. Write SQL statements with Python code大部分时间。它被编译到您选择的数据库中。它不适用于非常复杂的查询,但您始终可以回退到纯SQL。
  4. 使用alembic进行内置迁移。自动生成代码和大多数模式更改的所有数据库模式历史记录。
  5. 这是数据库和数据库驱动程序不可知论者。在内部,SQLAlchemy使用psycopg2或其他Postgres驱动程序。我记得没有ORM有它自己的驱动程序。曾几何时,我遇到了psycopg2(可能是我做错了什么)的unicode问题,只是更改了SQLAlchemy以使用其他驱动程序,并且工作正常。其他时间,我想运行我的应用程序PyPypsycopg2不支持。
+0

谢谢你的回答。 SQLAlchemy的确看起来非常引人注目,而且您可以使用普通SQL的事实看起来不错。然而,我想说的几点是,我很可能未来会改变我的部署,更重要的是,我可能不得不用复杂的JOIN编写查询。如果有人能说服我说'psycopg2'绝对不是不行,那么我一定会去看SQLAlchemy。 –

+0

SQLAlchemy用JOIN做了很多事情。有些时候,仅仅编写SQL更容易,而不是理解SQLAlchemy如何生成SQL。我只是试图给你一些自以为是的原因,但'psycopg2'很棒,即使SQLAlchemy使用它。 :)用'psycopg2'继续。 – iurisilvio

+1

你的回答给了我一些观点。现在我正在给SQLAlchemy一个想法。此外,发现一些有价值的信息[这里](http://stackoverflow.com/questions/8588126/sqlalchemy-or-psycopg2) –