2009-07-06 6 views
0

J'ai besoin de charger un modèle existant de +/- 20 tables de la base de données avec Entity Framework.Chargement d'une grande arborescence d'entités avec EF

Donc, il y a probablement quelques façons de le faire:

  1. Utilisez un énorme Inclure appeler
  2. multiplies Comprend les appels en itérer manuellement le modèle
  3. multiplies IsLoaded et appelle la charge

Voici ce qui se passe avec les 2 options

  1. EF crée une requête ÉNORME, met une charge très lourde sur la base de données, puis de nouveau avec le mappage du modèle. Donc pas vraiment une option.

  2. La base de données est appelée beaucoup, avec encore une fois de très grosses requêtes.

  3. Encore une fois, la base de données est appelée encore plus, mais cette fois avec de petites charges.

Toutes ces options pèsent lourd sur la performance. J'ai besoin de charger toutes ces données (calculs pour le dessin).

Alors, que puis-je faire? A) Opération lourde => charge lourde => ne rien faire :) b) Revoir la conception => mais comment? c) Une option magique qui fera disparaître tous ces problèmes

+0

Pourquoi voulez-vous faire? –

+0

J'ai besoin de faire des calculs CAO qui impliquent l'accès à une grande partie du modèle (sous un nœud spécifique).Pour savoir où un élément spécifique devrait être sur le dessin, j'ai besoin de savoir où est son parent, mais aussi son type et ses caractéristiques. Et cette logique s'applique à tous les éléments de l'arbre ... Cela a-t-il un sens? Si non, je vais vous expliquer un peu plus :) – Bertvan

+0

Fait maintenant très bon sens. ;-) –

Répondre

0

Lorsque vous avez besoin de charger beaucoup de données d'un manque de tables différentes, il n'y a pas de solution "magique" qui fait disparaître tous les problèmes. Mais en plus de ce que vous avez déjà discuté, vous devriez envisager la projection. Si vous n'avez pas besoin chaque propriété unique d'une entité, il est souvent moins cher de projeter les informations que vous avez besoin, à savoir:

from parent in MyEntities.Parents 
select new 
{ 
    ParentName = ParentName, 
    Children = from child in parent.Children 
       select new 
       { 
        ChildName = child.Name 
       } 
} 

Une autre chose à garder à l'esprit est que pour les requêtes très grandes, le coût de compiler la requête peut souvent dépasser le coût de l'exécution. Seul le profilage peut vous dire si c'est le problème. Si cela s'avère être le problème, pensez à utiliser CompiledQuery.

+0

Oui, je me souviens de votre suggestion précédente sur la projection. Cependant, créer une projection de ce modèle ne sera pas facile sur lui-même. De plus, c'est aussi une grande architecture, donc j'ai un peu peur que de nouveaux problèmes surgissent lors de l'utilisation de cette approche. Le coût de la compilation est en effet aussi une opération très longue (en ce moment), donc je vais certainement regarder dans l'option CompiledQuery. Merci – Bertvan

0

Vous pouvez analyser le rapport entre les requêtes et les mises à jour. Si vous téléchargez le modèle une seule fois, alors tout le reste est une requête, alors peut-être devriez-vous stocker une représentation XML du modèle dans la base de données en tant qu '"ombre" du modèle. Vous devriez être capable de lire la colonne XML entière en une fois assez rapidement, ou peut-être vous pouvez faire vos calculs (ou au moins la récupération des valeurs nécessaires pour les calculs) en utilisant XQuery.

Cela suppose SQL Server 2005 ou supérieur.