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

Question

我正在做一個需要頻繁訪問數據庫、插入和刪除的項目。 對於原始 SQL 命令，我應該使用 go 還是應該使用 go 技術？ 該項目可以在沒有任何對象且僅使用 SQL 命令的情況下正常工作嗎？ 這會影響一般的可擴展性嗎？

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

Answer 1

如果您對 ORM 沒有（或有限）經驗，那么學習新的 API 需要時間。 另外，您必須記住，犧牲“魔術”的速度。 例如，大多數 ORM 將 select 通配符“*”用於字段，即使您只需要Articles表中的標題列表。

而且 ORM 在特殊情況下會失敗。

從 OOP 的角度來看，大多數 ORM（基於ActiveRecord模式的 ORM）都存在極大的缺陷。 它們在您的數據庫結構和類/模型之間建立了緊密的耦合。

您可以將 ORM 視為技術債務。 這將使項目的開始更容易。 但是，隨着代碼變得越來越復雜，您將開始遇到越來越多由 ORM 的 API 的限制引起的問題。 最終，您將遇到無法使用 ORM 做某事的情況，您將不得不直接開始編寫 SQL 片段和整體語句。

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

Answer 2

我會說最好嘗試以最簡單的方式實現目標。 如果使用 ORM 沒有真正的額外優勢，並且應用程序相當簡單，我不會使用 ORM。 如果應用程序真的是處理大量數據，並且沒有業務邏輯，我不會使用 ORM。

這並不意味着您不應該設計您的應用程序屬性，但同樣：如果使用 ORM 不會給您帶來任何好處，那么您為什么要使用它呢？

Answer 3

為了加快開發速度，我會使用 go 和 ORM，尤其是在大多數數據訪問是 CRUD 的情況下。

這樣您就不必同時開發 SQL 和編寫數據訪問例程。

可擴展性不應該受到影響，盡管您確實需要了解自己在做什么（您也可能會損害原始 SQL 的可擴展性）。

Answer 4

如果項目面向： - 數據編輯（如查看簡單的數據表並對其進行編輯） - 性能（如設計最快的算法來完成一項簡單任務）

然后，您可以在代碼中使用直接 sql 命令 go 。

你不想做的事情是，如果這是一個大型軟件，那么你最終會得到很多類和大量代碼。 如果你在這種情況下，並且在代碼中到處散布 sql，那么總有一天你會后悔的。 您將很難對域 model 進行更改。 任何修改都會變得非常困難（除了添加功能或獨立於現有功能的實體）。

不過，提供更多信息會更好，例如： - 您所說的頻繁（多頻繁）是什么意思？ - 你需要什么性能？

編輯

看來您正在制作某種 CMS 服務。 我敢打賭，你不想開始用 SQL 填充你的代碼。 @teresko 的模式建議似乎很有趣，將您的應用程序邏輯與數據庫分開（這總是好的），但提供了自定義每個查詢的可能性。 盡管如此，添加一個填充 memory 對象的層可能比簡單地使用數據庫結果來編寫您的頁面需要更多的時間，但我認為您的情況並不重要。

我建議選擇一種將您的業務邏輯和數據訪問分開的良好模式，就像@terekso 建議的那樣。

Answer 5

這在一定程度上取決於時間尺度和您當前對 MySQL 和 ORM 系統的了解。 如果你沒有太多時間，就做你最了解的事情，而不是浪費時間學習一套全新的代碼。

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

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

這就是使用 OOP 編碼的好處——這樣的決定不必永遠束縛你。

Answer 6

我總是建議使用某種形式的 ORM 作為您的數據訪問層，因為在安全方面投入了大量時間。 僅此一項就是不自己動手的理由，除非您對自己在防范 SQL 注入和其他漏洞方面的技能充滿信心。