2016-04-25 90 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) –