在rails中直接編寫SQL查詢是一種很好的做法嗎？

我正在製作一個非常龐大的數據和多個連接的應用程序。立即在rails中使用完整的sql字符串是一種糟糕的做法嗎？在rails中編寫完整的sql查詢有什麼缺點？在rails中直接編寫SQL查詢是一種很好的做法嗎？

2012-03-15 phoenixwizard

很多複雜的查詢更容易和更清潔的SQL來表達，他們也是在SQL調整要容易得多。我一直這樣做，我也使用真正的FK，CHECK約束，觸發器和其他異端事物。 – 2012-03-15 07:21:32

我有時會走到商店，因爲除了坐車之外還有其他好處，即使有時我會被迫開車，因爲我不會以足夠快的速度到達那裏。就像編寫網絡應用需要花費更長的時間，如果我用原始SQL做它們的話。 OP詢問在使用旨在隔離他的框架（使其更好或更差）時使用原始SQL是否是個好主意。事實仍然是他沒有給出理由，爲什麼在他的特殊情況下他需要這樣做。我認爲，沒有特定的原因，這不是最佳做法。 – 2012-03-15 07:52:04

如果我們正在談論170萬種顏色將保持增加和數據庫在EAV模型！ – phoenixwizard 2012-03-15 08:32:44

如果你不理解備選方案，這只是一個壞習慣。

這就是說很少有理由這樣做。該框架爲你封裝它，好處是你必須編寫更少的代碼。另一個好處是數據庫獨立性。您編寫的查詢越直接，您將更有可能寫入在切換數據庫引擎時會中斷的內容。

這很容易測試。如果您正確地使用框架（即優化ActiveRecord，您會發現在許多文章中討論過），並仍覺得您的查詢太慢......您可以隨時對直接查詢進行基準測試。

但是不知道如何使用ActiveRecord關聯來做某些事情並不是訴諸直接SQL的好理由。

http://guides.rubyonrails.org/association_basics.html

來源

2012-03-15 07:04:31

數據庫獨立性在很大程度上是一個神話，沒有ORM會使您免受數據庫之間的差異。這就是爲什麼有那麼多的「它在SQLite的開發中工作，但用PostgreSQL打破了Heroku」的問題，以及爲什麼我們總是告訴人們在相同的堆棧上開發和部署。 – 2012-03-15 07:16:14

將一組開發人員安置在一個房間內，讓他們編寫一個除PHP以外沒有框架和直接SQL查詢的Web應用程序。然後把另一個類似的小組放在一個房間裏，讓他們用Rails或任何其他基於ORM的良好框架編寫一個Web應用程序，而不需要直接的SQL。你打算告訴我，這兩個組都會有相同數量的數據庫可移植性問題嗎？ – 2012-03-15 07:21:19

是的，我會說。顯示終結者可移植性問題（GROUP BY行爲，歸類問題，轉換，NULL處理邊緣情況，LIKE的區分大小寫，...）將是相同的，不重要的（像不同的標識符引用之類的東西）很容易修復，不值得擔心。我知道這一點，因爲我已經處理了這些問題多年，並且我看到足夠多的人盲目地信任他們的ORM，並且在部署時以有趣的方式破壞事件時必須重寫他們數據庫的重要塊。 – 2012-03-15 07:25:02

如果您需要功能更強大的語法比提供標準的ActiveRecord模塊，見meta_where寶石。

來源

2012-03-15 07:10:50 gayavat

SQL本身不是'壞習慣'本身。數據庫系統有很多原生的SQL方法，如果用Ruby編寫，執行起來會慢得多，編寫和維護起來也會更復雜。像Oracle的分析函數一樣。

也就是說，ActiveRecord的是很容易寫和你可能不會僅僅通過使用SQL查詢獲得的性能提升。至少不是如果你寫的查詢類似於ActiveRecord本來會寫的查詢！ ;）

也許你應該嘗試使用ActiveRecord並且只有在遇到問題時才使用SQL，否則你無法以另一種方式解決問題。這樣你就可以保持代碼簡單，直到你需要以另一種方式進行（即不要「儘早優化」）。我一般都試圖在ActiveRecord（或DataMapper或Sequel或其他）中工作，但是當我需要快速完成這項工作時，我肯定使用了finder_sql，並且我無法使用ORM的'sugar 」。其他時候，我在數據庫的單個海量視圖中創建了一個rails對象。

希望這會有所幫助。

：d

來源

2012-03-15 07:51:08

在rails中直接編寫SQL查詢是一種很好的做法嗎？

回答

相關問題