IV. Conclusion sur MS SQL Server 2005▲
Comme l'exprime très bien Joe Celko, dans son article " Keys to the Database" , je ne suis pas super enthousiaste à l'arrivée de SQLCLR, c'est à dire de procédures stockées écrite en .net, au sein de la base de données et exécutées sur le serveur...
Non pas que je trouve le langage C# mauvais, bien au contraire. Celui qui l'a écrit fait partie de mes "fans" et le style de la chose est plutôt parmi les projets intelligents comme le furent le langage ObjectPal de Paradox sous Windows (trop en avance dans ses concepts hélas), ou Delphi et son succès mérité (tiens, trois produits du même auteur ???). Non, là ou le bât blesse, c'est que, parcourant le net à la recherche de code SQLCLR pour expliquer ces concepts, je tombe deux fois sur trois sur du VB .net horriblement mal écrit. Et comment pourrait-il en être autrement avec un langage "à tout faire" écrit à l'origine pour les "débutants" (BASIC : Beginner 's All-purpose Symbolic Instruction Code)...
Que dire aussi du défaut d'impédande (NULL, collations, typage...) introduit par les L4G comme C# ? Je m'étonne par exemple à chaque fois de la complexité des solutions proposées pour résoudre ce problème dans les langages autres que SQL, et je m'étonne encore plus de l'absence quasi systématique de cette question dans le code que j'audite...
Bref, et comme me le disait un professeur d'université, " l'avantage c'est que n'importe quel couillon va être capable de pisser du C# pour faire sa petite fonction. L'inconvénient, c'est quand la fonction va devoir être appelée quelque centaines de milliers de fois dans les lignes d'une table balayée par un SELECT ! ". Car il y a fort à parier, comme c'est le cas actuellement dans les projets employant SQL Server, que peu d'entreprise mettrons un DBA costaud pour valider le code à intégrer dans la base...
D'autant que SQLCLR ne remplace pas Transact-SQL. En avril 2004, invité à titre de MVP chez Microsoft à Redmond pour discuter de la chose, nombre de MVP avait montré leur mécontentement : C# s'avérait moins bon que Transact SQL dans 2 cas sur 3 (c'est toujours le cas), mais l'aspect mercatique étant le plus fort, les microsoftees ne voulait démordre de cette stratégie. Le tohu bohu fut tel que la plupart des présentations que les équipes de développement de MS voulait nous montrer, s'arrêtaient à la deuxième diapo et il s'ensuivait des débats soutenu mais souvent constructifs. La conclusion fût amusante : certains MVP facétieux avait réalisé un tee-shirt sur lequel on voyait un "SQL Server" barré, remplacé per un rageur "CLR Server" !
La contrepartie de la systématisation de .net au sein de SQL Server c'est que l'on l'on va devant un marché sans doute juteux : MS sql Server 2005 va faire un tabac, et des gens comme moi vont devoir intervenir à chaud, lorsqu'au bout de quelques mois d'exploitation, la volumétrie tirera les performances vers le bas et que l'on saura pas comment optimiser l'application, c'est à dire rectifier les horreurs qui ont été écrites par des développeurs à la culture "base de données" restreinte !