Question performance avec SQL server 2000

Salut

Les gars du forum SQL m'ont dit que, de manière empirique, une proc stock est plus performante qu'une fonction tabulaire pour faire de la remontée de données.

Mais surtout il m'ont dit qu'il y avait des outils client pour gérer au mieux les proc stock. J'en ai donc déduis qu'ils voulaient parler de truc du genre : commandtype.storedprocedure

Bref, j'arrive à ma question : quel est, selon vous, le moyen le plus performant pour remonter les donnée et travailler avec, peu importe que ce soit pour les afficher ou les traiter. L'idée est vraiment de faire le transfert de données le plus rapide en le serveur de BDD et le serveur ASP.

Donc nous pouvons utiliser :

• un adaptater
• un objet comande avec un commandtype
• une datatable chargée par une fonction maison qui interprette une requête de type "exec maprocedure"

Merci pour votre avis.

c'est vite vu..

Les procédures stockées sont exécutées par le serveur SQL. Donc il ne te renvoie que le resultat. tu n as pas besoin de faire de traitement sur ton iis, autre que l'affichage


De plus ce qui est interessant tu peux lancer des requestes asynchrnoes si tu as un grand volume de données..


en espèreant avoir répondu à ta question.

Merci bossun. On va dire que oui, tu as répondu, mais j'ai pas bien capté.
Est ce que tu veux dire que la bonne solution c'est la DataTable qui reçois le résutalt d'un ProcStock ?

Attention, c'est un avis que je demande, je n'enguelerais personne parce que la solution n'est pas performante ou autre.

Combien accès simultanés prévois-tu sur ta base de données?

parce que si tu n'as pas beaucoup... ça sert à rien de se creuser là tete pour savoir qu'est-ce qui est plus performant ou pas...

Code:

---

Est ce que tu veux dire que la bonne solution c'est la DataTable qui reçois le résutalt d'un ProcStock ?

---

si il s'agit d'un Select simple.. je dirais que ça ne ser à rien de passer par une procédure stockée..


Mais si tu fais un traitement conséquent sur tes données avant de les renvoyer au client.. là je dirais oui il faut utiliser les procédures stockées...

@+

OK, je cormprends mieux.

Donc, oui, j'ai pas mal d'accès concomitant sur ma BDD et j'ai un gros traitement, avec des paramettres à faire pour extraire mes données.

Mais j'ai un peu l'impresison que tu réponds un poil à côté de ma question.
Le principe d'utiliser une Proc Stock est déjà établi par les gars du forum sQL Server.

Ma question porte sur la manière d'utiliser cette Proc Stock en ASP.NET et donc de choisir entre les trois méthodes que j'ai mis dans ma liste. Chacune des trois prenant pour base une Proc Stock

Vois tu mieux ce que je veux dire ?

désolé j'avais mal compris ta question... au fait j'ai lu trop vite :-)


alors là tu trouveras ton bonheur

http://msdn2.microsoft.com/fr-fr/lib...et(VS.80).aspx

MErci pour ton lien. J'ai bien lu, mais à part réviser le fonctionnement du DataSet, ça ne m'apprend pas grand chose sur les perf.

Parce que, ma question porte juste sur les perf, rien de plus.

Pour aller plus loin dans mon questionnement : aujourdh'ui j'ai un FrameWork Perso qui me permet de sortir des donénes de la BDD avec deux ligne de code. Ces données vont arriver sous forme de DataTable et sont appeléle par une requête SQL stockée dans un fiche de ressources. Cette requête peut prendre n'importe qu'elle forme tant qu'elle est valide.

Et la question grave que je me pose est de me dire s'il faut que je remette les mains dans le camboui de mon FrameWork Perso pour modifier la gestion des données ou pas. Donc je cherche la manière la plus performante pour remonter des données

Franchement pas trop clair ce que tu veux...

Mais si tu as qqch qui marche.. utilise le...

et si actuellement tu peux appeler que des requetes correctement formulées.. tu peux tres bien l'utiliser pour appeler des procédure stockée sans modifications..

au lieu d'une requete sql, tu va ecrir le nom de la procédure suivi des parametres.. comme suit

Citation:

---

"proc1 p1,p2,p2"

---

tu exécutes ce ptit bout de code est voilà,

J'espère que j'ai donné une reponse plus précise à ta question...

Merci vraiment bossun, mais désolé, tu es encore à côté de la question.

Bon, je reformule :
quelle est la méthode la plus performante en VB.NET pour recueillir des données :

1. un adaptater
2. un objet comande avec un commandtype
3. une datatable chargée par une fonction maison qui interprette une requête de type "exec maprocedure"

une seule réponse possible, un seul numéro à donner.

Voilà, c'est plus simple comme ça.

la 2..

tu exécutes la methode ExécuteReader() de ton objet commande.. c'est la plus rapide..

Merci, maintenant je peux refaire mon FrameWork, c'est malin .....


Bon, allez passse un bon Week-end je ferais la fête à mon FrameWork Lundi.
Quand je pense que c'est un mec ultra balaise en .NET qui nous a conseillé de faire un truc avec des DataTable, ben alors là...

Euh, James, si tu passes par là, salut.........

juste un truc.. avant de te lancer dans un une redéveloppement de ton framework demande toi ce que te permettra de gagner en performances..

si tu dois gagner dans le meilleur des cas 1 voir 2 secondes,, je ne sais pas si ça vaut la peine de refaire tout ton framework...

alors les datatables sont une couche intermediaire entre les données et le client.. c est qqch de différent. on s'en sert suivant les besoins.. si tu as une grosse appli OO, alors les dataTables sont privilégiés...

De plus si on est plusieurs a bosser sur la meme appli c'est mieux pask tu paratage les taches sans pietiner sur le boulot du collegue...

Franchement faut pas réinventer la roue...


Bon weekend à toi aussi

Meci pour tes encouragements et tes conseils.
Ne t'inquiète pas, lorsque je dit que je ve raafaire mon FrameWork, c'est une peu exagéré. Je vasi jsute rajouter une fonction qui traite les Proc Stock car il n'y en a pas et je m'aperçois que ça à l'air utile.

Le FrameWork en question permet de faciliter la tâche lorsqu'un développe.
On c'est aperçu qu'on tapait souvent les mêmes lignes de code pour appeller les requêtes (par exemple) et donc on a fabriquer des petites fonctions pour ne pas répéter inlassablement les choses.

On a développer aussi un truc qui permet d'envoyer un ou plusieurs mails en une ligne de code, plus les paramettre d'usage (mailto, mailfrom, message, subject, ...) le reste étant dans le fichier de config.

@+