Discussion :

[sephirostoy]

Bonjour,

j'ai généré un modèle de base de données via l'Entity Framework, et j'ai une table Employees avec les champs classique nom, prénom, ... et une propriété de navigation "Manager" qui pointe sur la table elle-même.

Voici ma requète Linq :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
List<Employee> emps = new List(
    from e in context.Employees
    where e.Manager == null
        && e.Name.ToLower().Contains(pattern)
    orderby e.Name
    select e);

En gros, je recherche tous les employés qui n'ont pas de manager et dont le nom contient le pattern que j'ai indiqué.

Sur 300 enregistrements, la requète me prend plus d'une seconde, et j'ai analysé sous tous les angles, 90% du temps provient uniquement de la condition [e.Manager == null].
Je comprends qu'il faut un peu de temps pour charger avant de tester la propriété de navigation; cependant ce qui me surprend beaucoup c'est que si j'exécute la requète plusieurs fois d'affilée le temps de réponse est toujours invarient.
Mon Context est le même durant toute la session, et est réglé pour faire du Lazy Loading.
Je pensais qu'avec ce mode, le temps d'exécution allait être un peu long la première fois, puis plus rapide par la suite.

Ai-je manquer une étape dans le raisonnement ?

PS: ma BDD est un fichier SqlCE.

[B.AF]

En gros tu utilises un ORM pour faire une requête SQL sur une zone non indexée en vérifiant la propriété de l'objet, sur une base SQL Ce locale et tu t'étonnes des perfs ?????

Déjà regardes la requête (ici); et eventuellement vérifie qu'il y a une indexation correcte des données dans la table.

Maintenant, on ne peut pas dire que tu as choisi un couple taillé pour la vitesse, donc...

[tomlev]

En gros tu utilises un ORM pour faire une requête SQL sur une zone non indexée en vérifiant la propriété de l'objet, sur une base SQL Ce locale et tu t'étonnes des perfs ?????

Déjà regardes la requête (ici); et eventuellement vérifie qu'il y a une indexation correcte des données dans la table.

Maintenant, on ne peut pas dire que tu as choisi un couple taillé pour la vitesse, donc...

quand même, une seconde pour 300 lignes ça me semble long, même en faisant un full scan...


@sephirostoy : est-ce que tu as une propriété ManagerId (la clé étrangère) dans ton entité ? Si oui essaie de tester plutôt sur cette propriété, ça évitera sans doute un left join...
Le problème c'est qu'un index ne changera pas grand chose en l'occurrence, vu que les nulls ne sont pas inexés (en tous cas c'est comme ça sous Oracle, pour les autres SGBD je suis pas sûr...)

[sephirostoy]

En gros tu utilises un ORM pour faire une requête SQL sur une zone non indexée en vérifiant la propriété de l'objet, sur une base SQL Ce locale et tu t'étonnes des perfs ?????

D'où ma question sur le lazy loading...
En gros je voudrais savoir si ma requète Linq sur mon context.EmployeeEntities va tout le temps taper dans la base et recharger à chaque fois les références ?

@tomley : oui ma table a bien une colonne Manager_ID. Cependant, j'accède à ma BDD via un ORM et du coup cette colonne là n'est pas visible depuis mon appli. J'ai uniquement accès à la propriété de navigation : employee.Manager.

[tomlev]

@tomley : oui ma table a bien une colonne Manager_ID. Cependant, j'accède à ma BDD via un ORM et du coup cette colonne là n'est pas visible depuis mon appli. J'ai uniquement accès à la propriété de navigation : employee.Manager.

C'est EF 3.5 ou 4.0 ? en 4.0 tu peux avoir la propriété de navigation ET la clé étrangère

Sinon, tu peux feinter et passer par du SQL, à l'aide de la méthode ExecuteStoreQuery. Mais bon, c'est un peu du bricolage

[sephirostoy]

J'ai EF 4.0 sous la main. Comment puis-je accéder à ma clé étrangère ?
Dans le code de la classe que me génère VS depuis mon modèle edmx, j'ai 3 sections : la méthode de création de classe, les propriétés primitives et les propriété de navigation.
Mais pas de signe de vie des clés étangères.

Sinon, autre méthode moins bricoloage. Je charge la liste complète de mes employés au début et quand je requète dessus, la référence sur le manager persiste dans mon objet, et les requètes sont plus rapides.
Etant donné que derrière je bind cette liste avec un champ de recherche qui filtre à la frappe temporisé, je pense que c'est ce qu'il y a de moins violent.

[tomlev]

J'ai EF 4.0 sous la main. Comment puis-je accéder à ma clé étrangère ?
Dans le code de la classe que me génère VS depuis mon modèle edmx, j'ai 3 sections : la méthode de création de classe, les propriétés primitives et les propriété de navigation.
Mais pas de signe de vie des clés étangères.

Je sais pas trop comment on gère ça quand les classes sont générées par le designer... Perso je travaille en POCO, je crée moi-même mes classes d'entités

Tu peux essayer d'ajouter manuellement la propriété ManagerId dans ton modèle et de la mapper sur la colonne Manager_ID, ça devrait marcher a priori

[sephirostoy]

C'est bon j'ai trouvé comment faire générer les clés étrangères dans le modèle.
Dans le designer, il faut remettre à jour le modèle depuis la base, et là on a la possibilité d'inclure les clés étrangères dans les entités.

Par contre Visual 2010 est très c**. Quand j'ai généré mes tables depuis mon modèle, je lui ai dit d'associer ma classe Employee à la table EmployeeEntity.
Quand je met à jour le modèle depuis les tables, ce blaireau me recréé une classe de type EmployeeEntities et détruit le mappage avec le type Employee. \o/

[tomlev]

Par contre Visual 2010 est très c**. Quand j'ai généré mes tables depuis mon modèle, je lui ai dit d'associer ma classe Employee à la table EmployeeEntity.
Quand je met à jour le modèle depuis les tables, ce blaireau me recréé une classe de type EmployeeEntities et détruit le mappage avec le type Employee. \o/

J'avais déjà vu ça dans VS2008, je pensais que c'était réglé dans VS2010 mais apparemment non