為何資料庫優先ORM模型在Go社群受到歡迎？ - Reddit

網友討論：
1. 我喜歡 Go 的主要原因之一是編譯時的型別安全。當你開始手寫SQL的時候，這一點就完全消失了。這讓人筋疲力盡。
我曾經用sqlx這樣的程式碼優先ORM模型完成過整個大型專案，儘管這比標準的lib方式要好得多，但你最終不得不重新發明輪子，或者做一些奇怪的黑客來一次插入多條記錄，特別是對於更復雜的關係。這樣一來，你就失去了整個程式碼庫與資料庫互動方式的一致性。

也許這只是我的看法，但我覺得一個可靠的ORM所具有的一致性、型別安全和整體測試量使得任何缺點都是微不足道的，特別是在一個大型的程式碼庫中。由於效能的原因，能夠編寫自定義的sql，這也抵消了一些關於這方面的擔憂。

資料庫是我們大多數人所做事情的基礎。我們寫的程式碼只是它上面的肉汁。如果資料庫包含了我們可能關心的所有資料的超級集合，那麼為什麼不倚重這一事實，並使用一個以一致的、經過測試的方式與之互動的庫。

我覺得很多人不喜歡 "魔力"，或者被ORM中表現糟糕的查詢所咬過。但我不知道能夠為特定的情況寫一個一次性的查詢，怎麼就不能解決這個問題。


2. 假設使用 ORM 的全部目的是幫助分離關聯式資料庫模型，並在構建業務邏輯時不再擔心基於 sql 的關係？
這是個糟糕的目標：你不能停止擔心基於sql的關係，它們是大多數服務效能的主要驅動因素。我花了一年多的時間在一家大公司擁有一個大型的、老舊的、被濫用的postgres資料庫，我無法告訴你使用活動記錄的人有多頻繁地引入N+1查詢（根據他們與記錄的關係找到一個id列表，然後使用for迴圈單獨查詢每個記錄），因為他們忘記了在他們完全普通的for迴圈的另一邊有一個資料庫。我無法告訴你這對資料庫的效能來說是多麼的糟糕。

每當你看到一個 "無程式碼 "產品的廣告，承諾PM和高管將能夠從頭開始構建整個產品，而不必與那些討厭的工程師打交道時，你無疑會翻白眼。ORMs是資料庫的無程式碼產品。不過，它們更糟糕，因為在我看來，對於PM來說，試圖在不花25萬買工程師或花5年時間學習程式碼的情況下完成更多工作是完全合法的。你是一個工程師！你是一個工程師。正確使用資料庫的能力完全在你的掌握之中!

所以，現在你有很多人因為某種原因想要一個ORM，但也許已經認識到忽視被執行的SQL是一個問題，所以現在你有了db-first ORM（資料庫優先ORM模型）解決方案。也許到時候，我們還可以把ORM完全乾掉。


3. Java 和 Go 之類的語言並非旨在為資料庫表建模。胡亂製作模型以便它們生成正確的表和高階查詢並不有趣。
關於 ORM，我最喜歡的一點是它們使基本的資料庫操作變得容易。CRUD 已經有了一個強型別函式。
DB-First ORM 提供了後者的好處，而沒有前者的成本。大多數樣板是自動生成的，所有非樣板我可以按照自己的意願去做。
編寫用於建立表的 SQL，只是想不為簡單的crud編寫SQL而已。


4. banq：DDD領域模型 != ORM中領域模型或資料模型，很多ORM大咖在ORM教程中往往把與資料庫表對映對應的資料模型稱為領域模型，這實際是錯誤誤導，因為領域模型不能依賴於資料庫等基礎設施技術，明白這個道理後，不如將ORM中資料物件模型或稱為實體模型與DDD的實體模型或聚合模型等領域模型區別開來，各搞一套。這樣，簡單的系統就無需DDD領域模型，系統複雜起來，就專門建立領域層，將ORM實體資料模型驅趕降級到基礎設施等DAO或持久層或DDD儲存庫Repository中，ORM 應該嚴格限制在 CRUD 中。