ORM性能成本

有沒有人通過選擇在SQL和手工設計的數據庫中使用ORM（在Django，RoR，SQLAlechemy等中）來指示開發人員可以期待什麼樣的性能？我想有一些複雜的問題，包括在ORM的約束範圍內指定數據庫是增加還是減少創建高效數據庫結構的機會（基於開發人員的經驗水平）以及開發人員構建SQL或基於ORM的查詢（再次基於他/她的經驗）。任何有關這些或內在性能問題的信息對我來說都會很有意思。ORM性能成本

來源

2009-01-16 jmans

你也可以不使用一個，並使用此：http://valueinjecter.codeplex.com/wikipage?title=Data%20access%20layer%20%28ORM%29%20with%20the%20Value%20Injecter&referringTitle=Home它是幾乎像一個orm，但你完全控制了所有的東西 – Omu 2010-07-29 11:47:57

我的建議是不要擔心，直到你需要 - 不要過早優化。 ORM可以爲開發速度，代碼可讀性提供許多好處，並可以消除大量的代碼重複。如果它會使你的應用程序更容易開發，我會推薦使用它。

在您完成開發使用基準和分析以確定代碼中的瓶頸時，如果需要，您可以繞過ORM並在需要的地方使用手動查詢。通常情況下，您可以使用緩存和數據庫索引（以及其他）來提高ORM的速度，然後您可以決定需要手動查詢的位置。在大多數情況下，ORM性能可能是可以接受的，使用它的好處遠遠超過性能成本。

來源

2009-01-16 20:33:28

是的，我同意這一點。 ORM可能會做一些很好的事情，你可能不會使用手動SQL優化而無需調整。 – 2009-12-23 07:29:00

使用IQueryables，包括（急切加載），投影 - 將使您的ORM（項目）更快......如需更多，我在本文中直接回答了其他2個鏈接。 – baHI 2017-02-26 10:53:35

這將取決於你的比較。編寫手寫代碼的編碼器是一個徹頭徹尾的黑客，它可能是一個福音，而不是一個命中。顯然它也可以以其他方式。

來源

2009-01-16 20:36:21 BCS

這也取決於你作爲一個ORM使用什麼。根據我的經驗，Hibernate在速度，資源使用和啓動時間方面都是豬。另一方面，LINQ to SQL是一個非常輕的SQL包裝器，其影響幾乎可以（如果有的話）通知。

來源

2009-01-16 20:40:28 TheSmurf

性能一直是大多數DAL層開發/體系結構中的一個想法。我認爲它的時候了，我們開始質疑這些ORM工具的性能，對於所謂的易於開發的，他們承諾：

在奧姆斯性能問題的2個最大的領域是：

無力編寫Optimum SQL。您必須使用由框架解釋爲SQL的對象查詢語言。大多數情況下，這是很好的SQL，但通常它不是最有效的SQL。
反射。大多數ORM框架使用反射來使用數據庫中的數據填充對象。反射操作昂貴，並且隨着負載和數據數量的增加，性能下降變得明顯。

出現的其他性能問題是由於實體對象與表緊密耦合導致數據庫設計或實體模型設計效率低下。

來源

2009-01-24 03:17:03 Ahmad

性能 - 其始終的利弊。如果您深入瞭解ORM 體系結構（請參閱我的文章：avoid ORM bad habits），那麼您會直觀地找到使其更快的方法。這是我關於如何使EF6x 5倍更快（至少在讀的情況下）的另一篇文章：EF6.x 5x faster

無論如何獲得良好的性能，即使ORM您將需要太創建數據庫視圖，索引，以檢查查詢由ORM生成並執行，並對其進行微調。 ORM必須加載加載。

來源

2017-02-26 10:51:32 baHI

回答

相關問題