Version imprimable
bonjour est il correcte(ou plutot non maladroit) d'écrire des méthodes avec de l'SQL comme instruction se trouvant dans la méthode sachant que les méthodes se trouvant dnas l'application seront présentées comme action devant un jury pour valider un bts informatique de gestion option développeur d'applications?merci
ca dépend de ta base de données. Si tu peux utiliser des procédures stockées, cela aide à la protection contre le SQL injection et les requetes sont optimisées au niveau performance.
maintenant, je te conseille de dire "du SQL" et pas "avec de l'SQL" car c'est pas de la confiture. et encore, il n'est pas question de maladroit ou non, de faire ceci ou cela, il n'y a pas de bonne solution par contre, à toi de justifier pourquoi tu as agis ainsi et pas autrement. Si le jury te demande pourquoi tu n'as pas fait de procédures stockées, tu te dois de trouver les arguments.
si je puis me permettre je suis egalement en Info Gestion (2ème annèe) et en matiere de serveur SQL ya un projet qui pourrais t'accorder les faveurs du jury
en tout cas c'est le mien :P
tu peut crèè une Librairy (fichier dll) contenant des fonctions et procedures qui te permettrons d'utiliser des serveurs SQL.
exemple:
Open
ExecuterSQL
LireDataTable
LireDataReader
ensuite dans un petit projet tout simple tu fait reference a ta belle librairy maison et tu dit
et la "voila l'utilitè de ma librairy! je peut maintenant effectuer des operations de plusieurs ligne en une seule!! biensur les methodes contenus dans ma librairy sont generalisè se qui me permet de l'utiliser dans tous mes projets et, étant compiler elle s'adapte ausi bien au C# qu'au VB.NET"Code:MaLibrairy.Open(localhost,root,password)
ma fois je pense que le jury aimeras et en plus l'interet pratique : tu va enormement te facilitè la tache quand tu créras des interfaces
Salut,
Comme l'as dit Louis, le plus important est de pouvoir justifier ses choix. Le Jury te demandera "Pourquoi avez-vous fait comme ça et pas autrement", et là tu devras te justifier en présentant des arguments valables, voir en présentant d'autres solutions et en disant pourquoi tu ne les a pas choisies.
Oh il s'appelle pas Louis, ni Guillaume mais Louis-Guillaume
Tout est affaire de justification.
Ensuite en développement, "professionnel" il est d'usage (pas dans ma boite, du moins les autres développeurs, qui développent comme des chartiers... et qui a mon sens mérite meme pas se statut) de séparer les responsabilités.
Cela permet d'améliorer la lisibilité du programme, et de faire du développement en équipe, plus facilement que dans un programme en code spaghetti.
De plus, cela améliore la productivité lors des cycles de tests/corrections, et du débogage du code.
Séparer les responsabilités, c'est commencer à s'orienter vers du développement N-Layers. (PAS N-TIERS n'en déplaise à certains qui galvaude ce terme, et d'ailleurs ce n'est certainement pas ce qu'on te demande pour un projet de BTS, car je doute qu'on te demande un truc hypercomplexe, avec architecture N-TIERS distribuée)
En d'autres terme, on range dans SQL tout ce qui est SQL, et on range dans le code tout ce qui est code.
exemple simple: un site web.
tu as une base de données, avec plusieurs tables...
et lors d'un affichage tu dois "consolider" les données d'une table par celles d'autres tables qui vont varier selon le besoin et le contexte (avec des contraintes a respecter et tout le toutim)
soit tu est un gros sauvage (comme 99% des pseudos-développeurs qui bossent ou ont bossés pour la boite ou je bosse), et tu met toutes les requetes dans ton code, et ensuite avec un beau FOR tu va prendre chaque ligne de ta table principale et faire un accès à la base pour avoir les données de consolidation...
là c'est le cas typique du code spaghetti qui n'engage que toi, et dans ce cas, tu dédie le serveur WEB à faire des traitements qui finallement pourraient etre fait ailleurs... qui ne sont pas de son ressort, qui pourrait répondre à des requetes d'autre personne sur d'autres chose pendant ce temps là mais ne peut pas car ta requete est trop consomatrice en terme de ressources...
Alors c'est sure dans certains cas tu n'a pas le choix, vu l'infrastructure logicielle dont tu dispose... MySQL 4 sans procedures stockées et pas compilé avec le support InnoDB... tu n'a pas trop le choix, surtout qu'il ne supporte pas les requetes imbriquées.
soit tu aime le code propre et tu sépare les responsabilités... là on pourra pas venir te tapper sur les doigts si c'est pas la partie que tu as codé qui marche pas... (meme si dans ton projet personnel de BTS ca n'a pas grande importance)
et dans ce cas ce gros traitement qui finallement n'est jamais que de la manipulation de données et de la consolidation de données, tu l'a dédié à celui qui est fait pour ca... il faut bien qu'il bosse, le SGBD. Et ho miracle... les SGBD digne de ce nom, supportent les procédures stockées... formidable non pour faire de la séparation de responsabilités.
L'intérêt c'est que si ton problème est purement dans la consolidation des données, tu le sais de suite, et tu va chercher là et pas ailleurs, et tu ne corrige que la, ou les, procédures/fonctions stockées concernées sans modifier ton code sous jacent.
Si demain pour des raisons techniques tu change la modelisation des données coté SQL avec les procédures cela restera transparant coté logiciel... faudra pas tout recasser et tout refaire, car tu pourra préserver le format retourné... ou au contraire modifier le format retourner sans pour autant modifier le stockage des données.
En plus, tu pourra laisser la possibilité à un DBA de modifier ce code SQL sans pour autant lui donner accès aux sources du programme car tu ne veux pas qu'il y touche. (c'est un peu les efforts qu'ont fait microsoft avec des technologies comme WCF qui sépare le code logique et la méthode pour y arriver... ainsi laissant à l'admin réseau le choix de définir lui même comment il souhaite que tes applis communiquent, port, protocole... ou dans WPF séparant le code logique de l'application, du Design laissant donc la partie GUI aux designers et pas aux développeurs.)
Autre avantage... tu minimesera le trafic entre le SGBD et ton application ou ton script web, dans cet exemple... car avec cette méthode tu as fait un appel et attend une réponse sous forme d'un ou plusieurs resultsets. Alors qu'avec l'autre, tu charge les deux process, et tu accroit le trafic entre les deux, car là tu n'a plus une requete, et N réponses, mais N + 1 requêtes et N +1 réponses, sous forme de multiple requêtes "non batchées", ce qui sera croit moi, beaucoup beaucoup plus long, car en plus une procédure stockée sera optimisée sous plusieurs points et aspects et toujours plus rapide que ton code spaghetti avec N appels au lieu d'un seul.
Le temps dont tu dispose sera aussi un facteur déterminant... séparer les responsabilités c'est plus long à développer, et à penser, concevoir, (du moins au début, après avec l'expérience ce n'est plus tout à fait vrai) mais c'est plus facile par la suite pour déboguer, ou modifier et agrémenter ton code de nouvelles fonctionnalités.
Personnellement, à part pour un projet où je ne devais pas justifier mes choix de codage et où seul le resultat comptait et vu que j'avais pas de temps à y consacrer, et l'ai donc fait méthode spaghetti... tout le reste est fait en séparant les responsabilités, au moins en séparant le code du SQL. maintenant le code est pas toujours avec une architecture N-Layers mais c'est quand meme plus facile à corriger.
J'ai un peu lu le post précédent mais pas tout parce que c'est quand même un gros plat de spaghettis tout ça ;)
Comment taper dans une DB proprement? Pour moi, il faut d'abord faire une interface pour s'abstraire du type de sgbd. Puis, implémenter la classe qui va taper dans la base. Rien de plus.
Le truc, c'est que si tu met ton SQL n'importe où, pour un peu que ton schéma change ou que tu change de sgbd, il faudra tout remodifier de partout. Avec cette solution, tu auras soit une nouvelle classe à développer pour ton nouveau sgbd, soit à modifier ta classe existante.
avec .NET l'accès aux données coté code ne pose pas de probleme pour les SGBD "principaux" graces aux CodeFactory fournies par le framework et de toute facon tu peux tjs fournir ton provider si ta un modele de base de données pas encore supportés.
Ensuite justement... il vaut mieux écrire tout ce qui est SQL dans SQL et ce qui est code logique dans le code.
15 requetes l'une après l'autres reprenant chaque des résultats de la précédentes pour ne finallement retenir que la requete finale n'a pas d'intéret et forme bel et bien un code spaghetti.
C'est illisible et nuit aux performances de facon assez significatives, car 15 requetes meme si elles sont optimisées avant exécution par SQL Server (et Sybase, et uniquement ces deux là) c'est toujours plus long que 1 requete, plus de trafic réseau, plus de mémoire, et beuacoup plus de temps.
il vaut mieux écrire une procédure stockée que tu devras certes peut etre réécrire d'un sgbd à l'autre...
l'intéret ?
Un SEUL appel pour remplacer 15 requetes que tu aurais géré coté client alors que c'est typiquement une tache serveur !
Si tu utilise ton SGBDR pour faire jste du SELECT * FROM ...
avec de temps en temps un ptit WHERE et que tu assemble les résultat coté client... UTILISER UN SGBDR N'A AUCUN SENS !!! et là tu peux utiliser une base de données ultra light style sqllite ou mysql3/4
a quoi bon payer un SGBD comme SQL Server pour une entreprise si les développeurs qui bossent dedans developpe toutes les requetes direct dans le code meme s'ils ont fait de beaux interfaces pour pouvoir changer de base de données sans probleme...
A RIEN... si a dépenser des sommes pharaoniques, suffit de voir les prix de SQL Server 2008 Enterprise Edition (et encore j'ai eu le prix revendeurs, pas les prix publics qui eux laissent songeurs) pour foutre sur des monstres à plusieurs processeurs pour se dire qu'on va y regarder à 2 fois !
En plus GroXX ca ne marche pas bien comme solution. Car ton code va dépendre du SGBD quand meme, et oui, tous les SGBD ne supportent pas la meme révision de SQL et les memes mots clés...
EXEMPLE TYPIQUE : le ptit mot clé LIMIT
pas supporté par Oracle ou SQL Server ou Sybase, enfin bref par les vrais SGBDR.
ensuite quand tu écrit la déclaration de certains objets comme les triggers... deja faut une base qui les supporte (c pas gagné)
ensuite par exemple pour oracle l'écritue differe de sql server (et de sybase)
si comme un gros porc tu écrit toutes tes requetes coté client... tu fait quoi ?
certes les objets nt les créé lors du déploiement mais le ptit mot clé LIMIT ou les requetes imbriquées, essaie de demander
à MySQL... tu va voir comment il va t'envoyer promener...Code:
2
Nota: les dernières versions de MySQL bien que supportant les procédures stockées dans une écriture semblable à celles d'Oracle.... ne supportent TOUJOURS pas ou du moins pas convenablement les requêtes imbriquées et les jointures non naturelles comme les RIGHT OUTER JOIN par exemple...
Tous les SGBD dignent de ce noms supportent les procédures stockées... Maintenant c'est sure que pour du vulgaire mapping relationnel/objet tu n'est pas obligé de foutre le code dans SQL Server, il vaut mieux le mettre dans des classes DAO spécifiques (programmation n-layers) mais néanmoins si tu as des suites de traitements purement SQL... il ne faut pas que ceux ci soit dans le code mais dans SQL... due moins c'est préférable.
En fait, c'est exactement ce que je fait, pour mon projet courant, j'utilise SQLite. J'ai supposé peut être un peu trop vite que notre ami flex@ travaillait avec ce genre de BDD.Citation:
Si tu utilise ton SGBDR pour faire jste du SELECT * FROM ...
avec de temps en temps un ptit WHERE et que tu assemble les résultat coté client... UTILISER UN SGBDR N'A AUCUN SENS !!! et là tu peux utiliser une base de données ultra light style sqllite ou mysql3/4
Par contre là je ne suis pas d'accord. C'est justement pour régler ce problème que j'utilise une couche d'abstraction. Bon, OK, j'aurais forcément une petite quantité de code qui dépendra du SGBD, mais au cas où je veuille changer de SGBD (ce qui n'arrive pas tous les jours, ni même tous les ans), je n'aurais qu'une classe à réécrire. D'ailleurs, ce type de solution est largement utilisé, que ce soit pour un SGBD, ou un lecteur de tags RFID, où n'importe quelle technologie matérielle ou logicielle sur laquelle on s'appuie.Citation:
En plus GroXX ca ne marche pas bien comme solution. Car ton code va dépendre du SGBD quand meme, et oui, tous les SGBD ne supportent pas la meme révision de SQL et les memes mots clés...