procédure stockée VS. application codée

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 :)

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+

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+

Citation:

---

Envoyé par Donpi

...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.

Citation:

---

Envoyé par Donpi

..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+

Citation:

---

Envoyé par 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+

---

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 +

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!

Citation:

---

Envoyé par Donpi

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+

Citation:

---

Envoyé par 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!

---

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?

Citation:

---

Envoyé par Lyche

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?

---

Mon expérience suffit a dire quand dans les cas que j'ai rencontrer ça n'était pas adapté (moi, pas 99% des développeurs, ni les plus grand expert du web, juste moi)
Après j'ai fait qu'une dizaine de boites mais a chaque fois les mêmes cas
- Un DB qui a entre 5 et 10 ans avec des erreur de modélisations a faire hurler
- Des centaines de tables dont une bonne partie obsolète d'autre avec des doublons
- Et pour le cas qui nous intéresses des centaines de procédures stockées dont la plus part ne font que de simples select ou sont en doublons ou pire.

Chacun est libre de penser/faire ce qu'il veux mais je reste sur ma position:
- Le règles métier reste dans le programme
- Une procédure stockée pour faire du SQL Simple est inutile et le gain de performance insignifiant

A+

PS: Un peut moins d’animosité et un peu plus d'échange les gars !

C'est ton côté catégorique qui m'énerve. Aucune solution n'est parfaite, et je te rejoins sur un point. Les devweb/applicatif, qui n'ont pas les connaissances des bonnes pratiques de développement des BDD, ne devraient pas avoir accès aux bases et à la conception de PS.

Mais de là à dire qu'il n'y a que les DBA, c'est trop. Je ne suis pas DBA, je suis spécialisé en SQL et une chose est sur, je m'ouvre les veine autant que toi lorsque je vois des projets faits par des devweb/app qui ont fait n'importe quoi juste parce que c'est pas leur métier.
De plus, pour avoir travaillé avec de nombreux DBA, beaucoup ne connaissent pas le SQL en soit, mais savent faire des procédures d'administration.. un DBA n'est pas forcément un spécialiste SQL.

La seule chose que je te reproche (et je me suis mal exprimé) c'est que tu es trop catégorique et tu ne prends absolument pas en compte le fait qu'il peut y avoir des dev spécialisé dans la BDD et qui savent ce qu'ils font.

Histoire de mettre mon grain de sel, je dirais que :

La prolifération des PS est à surveiller
Si le nombre de PS augmente considérablement, il y a de très grandes chances pour que :
- Elles tentent de pallier à des erreurs de modélisation, en rendant plus simple (ou pas) un mauvais agencement des tables.
- Elles ont une granularité trop fine, et pourraient être refactorisées afin d'en réduire leur nombre.
- Dans le cas d'anciennes bases de données, de nombreuses PS, au lieu d'évoluer, on été remplacées, sans qu'aucun ménage ne soit fait.

Et il faut bien garder à l'esprit, comme l'a si bien dit SQLPro, que cette "maladie", on la retrouve aussi dans le code client, et généralement de façon bien plus grave.
Combien de fois des bugs apparaissent parce que le simple calcul du total d'une facture exemple est implémenté de 25 manières différentes dans 20 programmes différents, avec des règles d'arrondi différentes ?

Les PS ont l'avantage d'être centralisées, et d'être exposées à tout le monde, mais aussi et surtout, de pouvoir être utilisées par les mécanismes d'intégrité (triggers, contraintes, colonnes calculées, etc.)

C'est donc bien des PS qu'il faut user et abuser, non pas de routines client qui seront bien plus difficiles à maintenir, et qui seront réécrite de façon différente par chaque intervenant dans chaque module, pour au final arriver à un plat de spaghetti incompréhensible et totalement buggé.