我開始接觸CodeIgniter，發現它支持Active Record模式。使用CodeIgniters Active Record庫來操縱MySQL數據庫還是應該使用SQL？
我喜歡它爲您生成SQL代碼的事實，因此您可以在不將應用程序綁定到特定數據庫引擎的情況下檢索，更新和插入數據到數據庫。
它使簡單的查詢變得非常簡單，但我擔心的是，如果不是不可能（例如，如果需要引擎特定的功能），它會使複雜的查詢變得更加複雜。
我的問題
什麼是你的這種模式特別是關於CodeIgniters實施的意見嗎？
在將數據庫封裝到另一個層中時是否存在速度問題？
嘗試構建非常複雜的查詢時，它（邏輯）會變得混亂嗎？
這樣做的好處是缺點嗎？
好的，首先，99％的查詢將會是簡單的選擇/插入/更新/刪除。對於這個活躍的記錄是偉大的。它提供了可以輕鬆更改的簡單語法。對於更復雜的查詢，您應該只使用查詢方法。那就是它的用途。
其次，它爲這些查詢提供了逃避&安全性。面對它，你的應用程序可能會有數百個甚至數千個查詢發生的地方。你一定會搞砸，並忘記妥善逃避其中的一些。活躍的記錄不會忘記。
第三，我的經驗表現沒有受到顯着影響。當然這只是其每個查詢的大概0.00001左右。我認爲這完全可以接受爲它增加的安全性和完整性檢查。
最後，我認爲它清楚地表明，我認爲這些優勢遠大於劣勢。有安全的查詢，即使是最初級的開發人員也能理解並且不會搞砸是件好事。
你對此模式的看法（原文如此）特別是關於CodeIgniters的實現嗎？
對CI的實現不能多說。除了最簡單的應用程序之外，通常我會避免使用AR。如果該表與我的業務對象不匹配1：1，我不使用AR，因爲它會使應用程序難以建模。我也不喜歡將持久層耦合到我的業務對象的想法。這是對關注點分離的違反。爲什麼產品要知道如何自救？ Futher閱讀：http://kore-nordmann.de/blog/why_active_record_sucks.html
編輯@kemp的評論後，我看着CI用戶指南，看看他們如何實現AR：
正如你可以看到PoEAA的AR是對象在數據庫表或視圖中包裝一行，封裝數據庫訪問，並在該數據上添加域邏輯。雖然這不是CI。它只是提供一個API來構建查詢。我知道有一個Model類擴展了AR，可以用來構建業務對象，但那會更像是Row Data Gateway。查看PHPActiveRecord以獲取備用實施。
在將數據庫封裝到另一層中時是否存在速度問題？
無論何時您將某些東西抽象或包裝到別的東西中，您都可以確定這會帶來性能上的影響。問題是，你的應用程序是否可以接受？唯一的方法是找出基準。進一步閱讀：https://stackoverflow.com/search?q=orm+slow
編輯在CI的簡單查詢構建API的情況下，我會假設性能影響是可以忽略的。組裝這些查詢在邏輯上比採用將原始SQL字符串傳遞給數據庫適配器要花費更多的時間，但這應該只有幾微秒。而且，就我在用戶指南中看到的那樣，您還可以緩存查詢字符串。但是，如果有疑問，基準。
嘗試構建非常複雜的查詢時，邏輯會變得雜亂嗎？
取決於您的查詢。我已經看到相當凌亂的SQL查詢。當通過面向對象接口表達時，這些不會變得更漂亮。根據API，您可能會發現通過它無法表達的查詢。但是，再一次，這取決於你的疑問。
這樣做的好處是缺點嗎？
只有你可以決定。如果它讓你的程序員變得容易，那肯定不行。如果它符合你的編程需求，是的。 Ruby on Rails很大程度上依賴於這個（AR）概念，所以它不會那麼糟糕（儘管我們也可以爲此爭論:)）
CodeIgniter的Active Record類不是一個ORM，它只是編寫（簡單）查詢的一種便捷方式。 – 2010-03-06 23:51:51
@kemp然後CI的AR類不是AR。但就像我在開始時所說的那樣：對於CI的實現不能說太多。 – Gordon 2010-03-07 10:05:28
+1 AR的好處遠遠勝過負面...... – 2010-03-07 16:06:57
我也在想這個。真棒回答，謝謝你！ – mdgrech 2010-11-06 17:58:51