原始SQL與基於OOP的查詢（ORM）？

Question

我在做一個項目，需要經常訪問數據庫，插入和刪除。我應該使用Raw SQL命令還是應該使用ORM技術？該項目可以正常工作，沒有任何對象，只使用SQL命令？這是否會影響一般的可擴展性？

編輯：該項目是用戶沒有提供我的內容，但用戶生成內容，並且項目在線的類型之一。因此，內容數量取決於用戶數量，如果項目甚至有50000個用戶，並且每個用戶還可以創建內容或閱讀內容，那麼最適合的方法是什麼？

Answer 1

我想說盡可能以最簡單的方式達到目的。 如果使用ORM沒有真正的附加優勢，並且該應用程序非常簡單，那麼我不會使用ORM。 如果應用程序確實是處理大量數據集，並且沒有業務邏輯，那麼我不會使用ORM。

這並不意味着你不應該設計你的應用程序屬性，但是，如果使用ORM不會給你帶來任何好處，那你爲什麼要使用它呢？

Answer 2

爲了提高開發速度，我會使用ORM，特別是如果大多數數據訪問都是CRUD。

這樣你就不必開發SQL並編寫數據訪問例程。

可擴展性不會受到影響，儘管您需要了解自己在做什麼（可能會損害原始SQL的可伸縮性）。

Answer 3

我總是會建議在數據訪問層使用某種形式的ORM，因爲在安全方面投入了大量時間。除非您對自己防範SQL注入和其他漏洞的技能感到有信心，否則這就是不推出自己的原因。

Answer 4

如果項目要麼導向： - 數據編輯（如查看數據的簡單表和編輯它們） - 性能（設計最快的算法做一個簡單的任務）

然後，你可以在你的代碼中直接使用sql命令。

你不想做的事情是，如果這是一個大型軟件，你最終得到許多類和很多代碼，那麼做這件事。如果你在這種情況下，並且你在代碼中隨處散佈sql，那麼總有一天你會很後悔的。您將很難對域模型進行更改。任何修改都將變得非常困難（除了添加功能或與現有功能無關）。

儘管如此，更多的信息可能會更好： - 頻繁出現的頻率如何？ - 你需要什麼樣的表現？

編輯

看來你正在做某種CMS服務。我敢打賭，你不想開始用SQL填充你的代碼。 @ teresko的模式建議看起來很有趣，將數據庫中的應用程序邏輯與數據庫分開（這總是很好），但可以定製每個查詢。儘管如此，添加一個填充內存對象的圖層比使用數據庫結果編寫頁面要花費更多的時間，但我認爲這種差異不應該影響您的情況。

我建議選擇一個很好的模式，分離您的業務邏輯和dataAccess，就像@terekso建議。

Answer 5

如果您對ORM沒有（或有限）的經驗，那麼學習新的API需要時間。另外，你必須記住，犧牲'魔術'的速度。例如，即使您只需要Articles表中的標題列表，大多數ORM都會爲字段選擇通配符「*」。

並且ORMs會在小生境中失敗。

大多數ORMs（基於ActiveRecord模式的ORM）在OOP的觀點上都存在極大的缺陷。它們在你的數據庫結構和類/模型之間建立了緊密的耦合。

您可以將ORM認爲是technical debt。這將使項目的開始更容易。但是，隨着代碼變得越來越複雜，您將開始遇到越來越多的問題，這些問題是由ORM API的限制引起的。最終，你會遇到這樣的情況，當不可能對ORM做些什麼時，你將不得不直接開始編寫SQL片段和entires語句。

我建議遠離ORM並在您的代碼中實現DataMapper模式。這會讓您在您的域對象和數據庫訪問層之間分開。

Answer 6

這取決於時間表以及您對MySQL和ORM系統的當前知識。如果你沒有多少時間，只要做你最擅長的事情，而不是浪費時間學習一組全新的代碼。

隨着時間的推移，一個像Doctrine或Propel這樣的ORM系統可以大幅度提高您的開發速度。當架構仍然發生很大變化時，您不希望花費很多時間重寫查詢。使用ORM系統，它可以像更改模式文件和清除緩存一樣簡單。

然後，當設計安定下來時，注意性能。如果您確實使用ORM並且您的代碼是可靠的OOP，則一次遷移到SQL一個查詢並不是一個太大的問題。

這就是使用面向對象編程的好處 - 像這樣的決定並不需要永久地綁定你。