用實體框架加載複雜查詢5

我正在爲ServiceTrips加載調度日曆，並想知道是否存在快速加載多個表中的相關數據的最快方法。用實體框架加載複雜查詢5

下面是需要加載模型（映射爲每個具體類型表）

public class ServiceTrip : BaseEntity 
{ 
    public ICollection<Employee> Crew { get; set; } 
    public ICollection<ServiceAssignment> Assignments { get; set; } 
} 

public class ServiceAssignment : BaseEntity 
{ 
    public ServiceOrder ServiceOrder { get; set; } 
    public DeliveryOrder DeliveryOrder { get; set; } 
} 

public class ServiceOrder : OrderBase { } 
public class DeliveryOrder : OrderBase { } 

public abstract class OrderBase : BaseEntity 
{ 
    public ICollection<ServiceAssignment> Assignments { get; set; } 
    public Sale Sale { get; set; } 
} 

public class Sale : BaseEntity 
{ 
    public Employee Manager { get; set; } 
    public Customer Customer { get; set; } 
    public ICollection<ServiceOrder> ServiceOrders { get; set; } 
    public ICollection<DeliveryOrder> DeliveryOrders { get; set; } 
} 

public class Employee : BaseEntity { } 
public class Customer : BaseEntity { } 

public abstract class BaseEntity 
{ 
    public int Id { get; set; } 
    public string Name { get; set; } 
}

我基本上試過這樣的事情，不知道從哪裏開始。

var tripsQuery = db.ServiceTrips 

.Where(x => x.StartDate >= FirstDay && x.StartDate <= LastDay) 

.Include(x => x.Crew) 
.Include(x => x.ServiceAssignments) 

.Include(x => x.ServiceAssignments.Select(y => y.DeliveryOrder)) 
.Include(x => x.ServiceAssignments.Select(y => y.ServiceOrder)) 

.Include(x => x.ServiceAssignments.Select(y => y.DeliveryOrder.Sale)) 
.Include(x => x.ServiceAssignments.Select(y => y.ServiceOrder.Sale)) 

.Include(x => x.ServiceAssignments.Select(y => y.DeliveryOrder.Sale.Customer)) 
.Include(x => x.ServiceAssignments.Select(y => y.ServiceOrder.Sale.Customer)) 

.Include(x => x.ServiceAssignments.Select(y => y.DeliveryOrder.Sale.Manager)) 
.Include(x => x.ServiceAssignments.Select(y => y.ServiceOrder.Sale.Manager)) 
;

該模型針對該問題進行了簡化。在製作中，我從大約20張桌子上拉出來。加載需要大約10-15秒。我試着每天異步加載，但增加了加載的總時間。

來源

2013-06-21 Benjamin

如果您在掃描的列上有索引，性能取決於很多因素，結果集的大小。我的建議是重現你在原始SQL中要做的事情，這會讓你知道你的查詢目前是否不合理。 –

由於沒有一個集合是'虛擬的'我會斷言數據是急切的加載而沒有任何'包括'的 – qujck

@qujck啊是的，這是正確的。這是我在簡化問題模型時犯的一個錯誤。它們在我的生產模型中是虛擬的，但我明確地禁用延遲加載。 – Benjamin

在當你發出的複雜查詢跨越你可能要與檢查數據庫本身

這裏開始的二十個表加入我看來是一些指導（有些點是相關的SQL Server中，我有冒昧假設在數據庫使用的是）

檢查對原始SQL查詢執行計劃 - 如果它是耗時重現整個EF代碼在SQL它只是也許部分 - 例如ServiceTrips，ServiceAssignments和DeliveryOrder表。這會給你的瓶頸的想法與問候指標等，
檢查，如果因爲數據的大小，網絡延遲是使用indexed views可能的瓶頸，而不是查詢本身
考慮提高你的表現
架構 - 爲了加快這種複雜的查詢使用某種形式的緩存可能存儲相關數據 - 在你的情況下，經理人也許是名字，船員等

來源

2013-06-21 05:42:33 eightyeight

謝謝。事實證明，這是幾件事情的結合。 – Benjamin

用實體框架加載複雜查詢5

回答

相關問題