tt à l'heure tu m'as proposé d'utiliser un fichier XML.Envoyé par Bluedeep
tu penses qu'elle est meilleure que creer plusieurs proc. stockées?(une proc. stockée par requete).
Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter
tt à l'heure tu m'as proposé d'utiliser un fichier XML.
tu penses qu'elle est meilleure que creer plusieurs proc. stockées?(une proc. stockée par requete).
ca part en vrille ce topic
il faudrait détailler la problématique de départ et s'y tenir
au dernières nouvelles c'était stocker les requetes pour les exécuter chacune leur tour même si y en a qui plante et pouvoir les afficher avec mise en forme
tu veux la mise en forme pour les modifier ou juste pour les créer ?
je veux juste stocker quelque part mes requetes de la façon la plus simple sans mise en forme. L'essentiel pour moi c'est juste de pouvoir recuperer le texte de la requete et de l'affecter à un sqlcommand et de l'executer.
Pour la modification , je les modifie simplement.
Par exemple si les requetes sont stockées dans un fichier texte alors j'ouvre celui ci par n'importe quel editeur de texte je porte ma modification , j'enregistre le fichier texte et c'est bon.
Si dans un fichier XML, je ferai de même j'ouvre le fichier XML meme avec n'importe quoi , je le modifie , je l'enregistre.
L'essentiel c'est de recuperer les requtes l'une apres l'autre.
Je ne sais pas si je suis clair.
Non, je n'ai pas proposé d'utiliser un fichier XML, j'ai juste dit que c'est la solution que je choisissais pour stocker les requêtes quand j'utilise SQL CE.
Car SQL CE ne permet pas l'usage des proc stoc.
Et du XML car c'est infiniment plus simple à lire et à parser qu'un fichier texte.
Non, encore une fois je n'utilise cette solution que pour SQL CE.tu penses qu'elle est meilleure que creer plusieurs proc. stockées?(une proc. stockée par requete).
Elle est bien inférieure, mais quand je ne peut pas avoir de proc stoc, faut bien un moyen d'externaliser les requêtes.
Comme dit Pol63, il serait temps de revenir à ton besoin fonctionnel car ça part dans tous les sens.
et bin tu mets tes requetes dans une table et t'arrete de nous emmerder !
lol
désolé c'était juste pour le trip de continuer crescendo ^^
enfin avec tes requetes dans une table y a rien de compliqué
donc soit tu le codes soit tu as une autre question, mais on va arreter de tourner autour du pot avec les 15 millions de méthodes de stockage existantes
Mon besoin fonctionnel est de transferer avec un programme C# des données d'une base de donnée vers une autre. C'est comme ça que veut le chef de projet technique.
J'ai créé des requetes sql qui vont me faire ce travail.
ces requetes je dois les stocker quelque part?
voilà.
ok je vous laisse tranquille; merci à vous
Pol63 et Bluedeep et les autres.
là je me suis assez perplexe, et en fait assez amusé par la tournure de cette discussion...
pour faire simple, on te propose une série de solutions, dont la plus propre qui consiste à traiter tout ce qui attrait à SQL dans SQL... via les procédures stockées.
maintenant si tu rejette ces solutions pour des raisons obscures basées sur des affirmations fantasques et totalement dénuées de fondement, cela ne regarde que toi, mais dans ce cas ne vient pas demander si tu veux qu'on réponde comme toi tu l'aurais "pensé" et fait directement comme tu l'aurais pensé...
Maintenant petite question préalable avant de parler CHARGE... tu utilise quel SGBDR ?
Je t'explique une procédure stockée, qu'elle soit T-SQL ou SQLCLR, ce n'est que du code qui est stocké... quelques octets tout au plus... EN AUCUN CAS le résultat de la requête, mais si ca peut te rassurer, pour une vue c'est exactement le même principe, ce n'est pas son résultat qui est stocké mais la requête qui sert à la créer.
Alors ne vient pas nous parler de charge sur un vrai SGBDR... maintenant c'est sure que si ta base est base MySQL... j'y regarderais à 2 fois, mais en SQL SERVER... faut pas exagérer non plus...
et puis sais tu seulement ce que charger un serveur veut dire ?
Sql Server est un vrai SGBDR, on peut lui faire gérer des base de données largement plus grosses que ce tu imagine dans ton pire cauchemard...
on peut calibrer comme ceci pour une base en fonction de sa volumétrie:
- < 100mo, tu peux largement utiliser MySQL ou meme plus uniquement si tes données sont des DATAMARTS...
- > 100Mo et < 10Go : Sql server 2008 Express
- > 10Go et < 200Go : SQL Server 2005/2008 standard, surtout si ta base n'est pas de types tables planaires mais est un datawarehouse.
- > 200Go : un gros datawarehouse avec des années de passif... on va préconiser une ferme de SQL Server 2008R2 entreprise (réplication et tout le toutim).
Depuis SQL Server 2008, et tout particulièrement la R2... ce n'est plus du tout la peine d'envisager de passer à Oracle je dirais même que puur tout projet de volumétrie > 200Go il est préférable de passer à SQL Server que Oracle sous windows...
Alors excuse moi du peu mais quand on parle de charge, on sous entend une vraie volumétrie... et je doute que tu travail sur de telles volumétries au vue de tes questions et croyances infondées...
si ta base dépasse les 100mo c'est déjà pas mal, alors, ce n'est pas une pauvre procédure stockée qui va faire la différence, et quand bien même elle serait stockée en T-SQL plutôt que précompilée...
Et si tu parle de charge en temps d'exécution...
Lancer toi même séquentiellement les requêtes l'une après l'autre, c'est typiquement ce qu'on appel du syndrome N + 1 ce qui est abbération en terme de design pour du développement avec serveur de données, et tu va charger à mort ton réseau, et ce sera TOUJOURS plus long qu'une procédure stockée...
Lancer une procédure stockée qui en lance d'autres, ou qui exécute des requêtes stockées dans une table, pourquoi pas. Car après tout, tout ce qui est SQL doit rester dans SQL pour améliorer les temps et diminuer la charge réseau et le trafic parasite, qui va te pénaliser si effectivement tu as une volumétrie et donc une charge importante.
je vais te pondérer un peu cinemania ^^
c'est du code source + 1 à plusieurs plan d'exécution, et ca peut prendre un peu de place ^^Je t'explique une procédure stockée, qu'elle soit T-SQL ou SQLCLR, ce n'est que du code qui est stocké
m'enfin je chipote car pour une requete qui passe ca fait la même chose
on ne peut pas affirmer ca non plus, la taille de base que peut gérer un sgbdr dépend de la structure de la base, du nombre de clients, de la fréquence des requetes, de la qualité d'écriture des requetes, de la maintenance mise en place etc...Sql Server est un vrai SGBDR, on peut lui faire gérer des base de données largement plus grosses que ce tu imagine dans ton pire cauchemard...
pour un même projet avec une base de taille identique et un même pc on peut ainsi voir sql server utiliser de 1% à 80% du processeur et de la ram selon les paramètres précédemment évoqués
D'accord avec toi sur tout, sauf que je trouve tes chiffres vraiment très prudent.
En effet :
De mon expérience personnelle (qui vaut ce qu'elle vaut mais bon ....)
Avec Sql Server 2000, j'avais UN client qui avait des bases Sql Server autour du tera. Les autres (volumétrie similaire) utilisaient Oracle.
C'était moins rapide chez celui qui utilisait Sql Server que ceux qui utilisaient Oracle (avec la même appli qui sortait de chez l'éditeur où j'étais chef de produit).
Avec Sql Server 2005, le "tera" est devenu monnaie courante dans le monde Sql Server; l'avantage Oracle commençait à se réduire comme peau de chagrin.(dans certains cas, on allait plus vite avec Sql Server dans d'autres non).
Avec 2008 R2, en effet, n'en parlons plus, ite missa est. Sans même parler de la qualité époustouflantes du BI de cette version.
merci à tous.
un peu d'humilité n'a jamais fait de mal.
pol63 tout dépend de ce qui est entendu par charge ...
volumétrie ou temps d'exécution ...
et puis bon... je doute que son problème soit si coriace qu'il nécessite un mainframe pour être exécuté...
c'est sure qu'interroger une table de 15Go dans une base qui en fait 1500... là faut être sure de son coup... mais bon... même là, il est préférable d'avoir recours à une procédure stockée, surtout que ca réduira le trafic parasite entre son application et SQL Server.
on parle quand même d'un SGBDR professionnel, pour des grosses infrastructures, on parle pas d'un sgbd et d'une utilisation tout public ou mysql même sans intégrité relationnelle suffit amplement.
effectivement Bluedeep j'ai connu, un client que j'ai fait migrer d'un SQL Server 2000 a 2005 pour sa base de 1To
au début il pensait passer à oracle, mais vu la machine destination, le prix des licences pour oracle lui a fait faire un AVC (ba oui pour oracle, une licence par processeur signifie une licence par COEUR pour des processeurs multi-core...)
et une fois migré vers SQL Server 2005 leur temps se sont réduit pour devenir inférieur à ceux de l'infrastructure du siège social toujours sous oracle (avec une facture nettement moindre en licence logicielle)
tu verrais le nombre d'entreprises qui utilisent sql server sans le connaitre juste parce que c'est populaire (et donc le nombre de bases mal faites)
ca a beau etre un sgbdr professionel, ceux qui l'utilisent ne le sont pas forcément et du coup les perfs elles ne sont pas au rendez vous
là ou je bossais avant pour une base de moins de 10Go il y avait des procédures stockées qui duraient 10 heures
je me rappelle j'avais même modifié une fonction scalaire qui faisait moins de 10 lignes et je l'ai passé de 2 minutes d'exécution à quelque chose de l'ordre de la seconde
(base avec des PK clustered varchar contenant des données et autres excentricités ...)
pol63, oui mais dans ce cas, quelque soit le SGBDR... les performances ne sont jamais au rendez vous... même sous Oracle à l'époque de SQL SERVER 2000.
et effectivement dans son cas, faire des requêtes l'une après l'autre par son application, au lieu de le faire par une procédure stockée, va plomber significativement les performances.
dois je utiliser une proc stockée par requete ou une seule prcocedure pour toutes les requetes?
je dirais que ca dépend des requêtes et de la façon dont tu veux gérer les erreurs.
a priori rien ne t'interdit d'utiliser une procédure stockée qui en appelle d'autres... si tu veux garder une plus grande souplesse et lisibilité qu'une énorme procédure stockée qui deviendra vite illisible, maintenant je pense qu'il y a des cas où il vaudra mieux tout remonter en une seul et dans d'autres fragmenter... il n'y a pas de recette toute faite, mais il est possible quand on travail avec SQL Server d'avoir la trace du plan d'exécution, et cela permet de faire des essais et tester quelle solution est la plus efficace.
c'est mieux que d'en avoir 50 et de les appeler toutes l'une après l'autre depuis ton appli, au moins si tu veux changer de design ou passr à 100 procédure au lieu de 50, se sera transparent pour ton applicatif, il faudra juste changer ta "méta" procédure stockée.
ramener les requetes coté .net pour les relancer ne va pas non plus plomber les perfs, ca perd juste quelques octets et l'aller retour à chaque requete, en local c'est insignifiant par rapport au temps d'exécution je pense
(enfin si c'est bien des requetes du type insert into table (...) select ... from autre table comme je l'ai compris)
quand j'appelle ma requete depuis mon application, ou que cette meme requete je la met dans une procedure stockée , en terme de performance quelle est la bonne solution? et pourquoi?
ca depend de la requete
si c'est si c'est requete du genre DELETE FROM TelleTable WHERE TelleCondition
ou l'appel de la procédure stockée contenant cette requete via EXEC MaProcStock
tu gagnes 2 octets par caractère en moins à envoyer par tcp/ip en passant par la procédure stockée
une même requete exécutée 2x peut avoir de méthode d'exécution différente choisir par sql server ... pour une procédure stockée, sql sever enregistre des stats sur les méthodes utilisées et donc il choisies celle qui va lui sembler la plus performante à cet instant T
mais pour une requete aussi il stocke des plans d'exécution donc en théorie ca revient au même ...
après cinemania va peut etre me dire le contraire, mais bon ce n'est pas sur un thread de forum qu'on pourrait expliquer le fonctionnement d'sql server, alors qu'un intervenant dans la partie sql server de ce forum (professeur en école d'ingé sur sql server de son état) me disait que 2 ans d'enseignement ne suffisaient pas pour voir sql server en détail ...
comme a été dit précédemment, si tu veux modifier ta requêtes tu n'es pas obligé de recompiler ton appli, et puis ça t'évite d'envoyer la requête vial le réseau ( donc plus performant).
Répondre avec citation
Partager