Discussion :

[vittel31]

Bonjour

actuellement je travaille sur SQL server et quotidiennement des mises a jours sont effectuées sur les tables dont je m’occupe. Les données sont récuperées sur plusieurs serveur et bases de données (notament des bases de donnée Oracle .. ).
Est-ce préférable d’effectuer les mise à jours dans le code d’une application ou de se servir des procédure stockée (procédure dont j’ignore s’il est possible d’aller chercher de l’information sur d’autre serveur).

J'Ai beaucoup d'intérêt pour les sp (procédure stockées) qui permettrai d'alleger le travail de mon ordi ainsi que d'Accelerer les différentes mise a jours. JE nai actuelement que peu de connaissance sur les sp, je vous demande conseil car le temps me manque et je ne voudrais pas consacrer ce temps précieux à apprendre en profondeur quelque chose dont je ne me servirai pas dans un futur proche.

merci

[hmira]

L'intérêt à utiliser les procédures stockées sous SQL Server, est manifeste.

En outre, il est tout à fait possible, Sous SQL Server, depuis une procédure stockée, d'aller chercher, voire même mettre à jour, des données provenant d'autres serveurs de base de données, en l'occurrence ORACLE. Pour cela, il suffit de créer, sous SQL Server, des objets "Serveur lié".

http://msdn.microsoft.com/fr-fr/library/ms190479.aspx

A+

[Donpi]

Bonjour,
Personnellement je suis contre la prolifération des procédures stockées.

Au niveau performance c'est quasi similaire, en revanche au bout de qqes années de vie, la db est POURRIE par des procédures stockées dont personne ne sait a quoi elle servent et qui sont difficile supprimable car il y a toujours le bout de code super important qui l'utilise une fois par ans.

Les procédures stockées devraient resté la propriété du DBA et non du développeur.

A+

[hmira]

...Personnellement je suis contre la prolifération des procédures stockées.
Au niveau performance c'est quasi similaire, en revanche au bout de qqes années de vie, la db est POURRIE par des procédures stockées dont personne ne sait a quoi elle servent et qui sont difficile supprimable car il y a toujours le bout de code super important qui l'utilise une fois par ans.

Ce n'est pas parce la création des procédures stockées n’est pas encadrée, effectuée de manière non réfléchie, etc. qu’il faudra bannir les procédures stockées.
Il est vrai, que dans certaines situations, malheureusement pas rares, lorsque n’importe qui, pour n’importe quel besoin, écrit à la volée une plusieurs procédures stockées, parce qu’il trouve que ça fait bien, et ce, sans même se concerter avec le reste de l’équipe, évidemment, cela peut rapidement aboutir à des situations chaotiques avec une prolifération de procédures stockées non documentées, souvent même avec des doublons !
Les procédures stockées doivent faire l’objet de spécifications fonctionnelles détaillées, avant leurs implémentations. Les procédures stockées traduisent généralement des règles de gestions métiers, immuables (enfin jusqu'à la prochaine évolution !), partageables et communes à toutes les applications frontales (ou IHM).
Mon expérience personnelle me conforte dans l’idée que les procédures stockées, lorsqu’elles sont bien spécifiées, documentées etc. contribuent à améliorer de façon notable et la qualité et les performances des applications.

..Les procédures stockées devraient resté la propriété du DBA et non du développeur.

Le DBA peut, s’il le juge utile, pour ses propres besoins d’administration système, bases de données, écrire des procédures stockées orientées administration (exemple : procédure de Rebuild des indexes dont le taux de fragmentation dépasse le seuil de 30% et de Réorganisation des indexes dont le taux de fragmentation est compris entre 5 et 30% etc.. ) Il n’est généralement pas de son rôle, à moins qu’il ait une double casquette, Développeurs et/ou Administrateur, d’écrire des procédures stockées orientées règles de gestion métiers.

A+

[SQLpro]

Bonjour,
Personnellement je suis contre la prolifération des procédures stockées.

Au niveau performance c'est quasi similaire, en revanche au bout de qqes années de vie, la db est POURRIE par des procédures stockées dont personne ne sait a quoi elle servent et qui sont difficile supprimable car il y a toujours le bout de code super important qui l'utilise une fois par ans.

Les procédures stockées devraient resté la propriété du DBA et non du développeur.

A+

Votre posture est stupide...
1) sur les performances.... vous dites n'importe quoi ! Une procédure qui effectue une dizaine de requête ne fait qu'un seul round-trip sur le réseau. La même côté client en fera 10 !
Or les temps réseaux sont généralement les temps les plus pénalisant. De plus si le traitement est encapsulée dans une transaction, vous allongez d'autant le verrouillage des tables (en lecture comme en écriture) ce qui pénalise la concurrence et créé de la contention !

2) Croyez vous qu'en interdisant l'écriture des SP par les développeurs, ceci leur empêchera de faire la même merde côté client ? En sus il est extrêmement facile dans un serveur SQL d’auditer les objets qui servent de ceux qui ne servent plus... Allez-donc faire cela dans du code client et vous m'en direz des nouvelles !

Moralité c'est avec des commentaires comme les vôtres que se répandent sur Internet des contre-vérités !

A +

[Donpi]

Monsieur SqlPRO on reste poli !

Ma "posture" répond a mon expérience, il s'agit de la réalité et non de ce que j'ai lu dans des livres.
Donc tout sauf stupide !

Personnellement = Mon avis! On prend ou on jette!

[hmira]

Ma "posture" répond a mon expérience, il s'agit de la réalité et non de ce que j'ai lu dans des livres.
Donc tout sauf stupide !

Tu connais le proverbe latin :
"Errare humanum est, perseverare diabolicum" (L'erreur est humaine, persévérer est diabolique !).

Ta posture actuelle est indéniablement maladroite.

Sans rancune,

A+

[Lyche]

Monsieur SqlPRO on reste poli !

Ma "posture" répond a mon expérience, il s'agit de la réalité et non de ce que j'ai lu dans des livres.
Donc tout sauf stupide !

Personnellement = Mon avis! On prend ou on jette!

En gros, ton expérience seule suffit à démontrer que 99% des développeurs de BDD, ainsi que les plus grands experts du métier sont dans le faux?