Linq to sql : Avis

Salut,

Citation:

---

Envoyé par WOLO Laurent

Toutefois il faut que tu fasses ressortir des tests qui pouverais que Linq + Cmd par exemple serait plus rapide que le SQL Standard

---

Il faut regarder le tableau ici: http://immobilis.developpez.com/tuto...amework/#LIV-G.

http://immobilis.developpez.com/tuto...PerfAllTab.png

Sauf erreur, deux cycles de tests indiquent que le fournisseur SQL est plus lent lors de 1000 lectures des 8000 enregistrement de la table (procédure stockée "SelectAllCustomers"). Comme je l'indique, il faut relativiser. Ce résultat est obtenu sur mon portable et pour avoir plus de précisions, il faudrait le faire dans un environnement matériel plus adapté. Malheureusement, je n'ai pas cette possibilité en ce moment. Si quelqu'un peut faire le test ce serait cool. J'ai laissé les sources.

J'avais ouvert une discussion sur cette interrogation il y a longtemps. Les résultats aboutissaient aux mêmes conclusions. Cependant, dans un environnement avec des serveurs en RAID et séparés le SQL Standard l'a finalement emporté. Ouf :)

Maintenant, tout n'est pas simplement affaire de rapidité de la DAL. Comme me disait iberserk: "les performances seront moindres, dans 80% des cas ce n'est pas un problème car une application de gestion travail sur des volumes en majorité faibles et ce n'est pas parce que vous passez de 250ms à 300 que l'utilisateur le verra". A un certain niveau, l'intérêt est ailleurs.

A+

Immo

Citation:

---

Envoyé par Immobilis

J'avais ouvert une discussion sur cette interrogation il y a longtemps. Les résultats aboutissaient aux mêmes conclusions. Cependant, dans un environnement avec des serveurs en RAID et séparés le SQL Standard l'a finalement emporté. Ouf :)

---

Heureusement, que c'est déjà débatu et l'on connait la conclusion, :mouarf:


Je voulais aussi te faire noter un petit fait :
La création et la suppression des données dans ta table via des transactions pilotées par ADO.Net, tu l'aurais fait en un seul roud-trip et dans une procedure stockée global, nous sommes entrain de rechercher les perfs.

Citation:

---

Envoyé par WOLO Laurent

La création et la suppression des données dans ta table via des transactions pilotées par ADO.Net, tu l'aurais fait en un seul roud-trip et dans une procedure stockée global, nous sommes entrain de rechercher les perfs.

---

Pas sur cette opération. Je ne teste que le CRUD. D'ailleurs, je n'ai pas implémenté cette méthode sur les autres fournisseurs.

J'aurais aimé que tu fasses cette modification même si elle ne rentre pas en ligne de compte dans les tests. Ca sera publié et je souhaite vivement que les meilleurs pratiques soient toujours publiées dans nos codes afin que les newbes puissent les adopter même sans les comprendre (Théorie de Goering)

Citation:

---

Envoyé par WOLO Laurent

les meilleurs pratiques soient toujours publiées dans nos codes

---

C'est très relatif. Ce n'est pas à mon sens une mauvaise pratique que de faire appel à deux procédures stockées différentes. La mauvaise pratique eu été de le faire en dehors d'une transaction par exemple. Je devrais peut-être simplement tester le retour de l'exécution de la première requête.

[EDIT]Aie, exemple de mauvaise pratique, utiliser un objet disposable sans le "using". J'ai corrigé le CustomerManager :P

Code:

---

1 2 3 4 5 6 7

public void DropCreateTable() { using (SqlCustomerProvider provider = new SqlCustomerProvider()) { provider.DropCreateTable(); } }

---

[/EDIT]

En effet, si on considère la responsabilité de la BLL/Base de données, il appartient à la BLL de faire appel à l'une ou à l'autre ou aux deux. C'est le métier qui décide, pas la base :P Mais j'arrête car ça sens le troll :aie: ;)

Citation:

---

Envoyé par WOLO Laurent

les newbes puissent les adopter même sans les comprendre

---

Euh...