Discussion :

[JPLAROCHE]

bonjour ,

je me pose des questions est-il plus judicieux de programmer sa base de donnée directement par le langage dans lequel on programme.

Je vois des tutoriels intéressant avec de la programmation PL des Procédures stockées fonction, etc…

Ma question peut paraître idiote...

J'ai peur que mes procédures stockées m'oblige à reprendre les programmes ... Donc une maintenance supplémentaire. En considérant que la data-base est correctement définie

Quel sont les avantages des procédures stockées, personnellement j'arrive d'entreprise ou tout est fait dans les programmes et chaque programme est indépendant et résout son problème ...

Deuxième question n'est-ce pas déporté le problème le langage PL des Procédures stockées, hormis mettre dans les mains de grand utilisateur la base de donnée (ce qui est mon avis dangereux au vu de mon expérience) ou alors hors base crucial de l'entreprise.

Les seuls fois ou j'ai fait cela ce sont avec les trigger et encore pour la conversion de devise, etc...

[SQLpro]

Cela dépend de deux facteurs :

• performances
• mise à jour sans interruption

J'ai écrit de nombreux articles sur le sujet.... Le plus complet est celui-ci :
http://sqlpro.developpez.com/cours/b...s-epaisses.pdf

Si vous voulez des performances, le fait d'utiliser des procédures stockées pour manipuler des données évite de multiples problèmes :
1) Lorsque l'on développe sans procédures stockées et en mettant tout dans les programmes applicatifs, la majeur partie du temps est passé dans les "round-trip", c'est à dire les aller et retour réseau entre l'application et le serveur SQL. Alors qu'en utilisant des procédures stockées (dont l'exécution s'effectue au sein du serveur SQL) ces temps n'existent pas
2) du fait de cet allongement des temps d'exécution lorsque l'on fait tout le travail au niveau applicatif, la durée des transaction est très sensiblement allongé, or toute les transactions nécessitent la pose de verrous. Problème, plus les verrous durent longtemps, plus les utilisateurs concurrents doivent attendre (donc, baisse des performances) ou relancer certaines commandes du fait d'anomalies transactionnelles. Pire : plus les blocages sont long, et plus statistiquement (et stochastiquement) vous avez de chance de générer des verrous mortels....

Enfin, un SGBDR étant dynamique, y compris dans son codage, vous n'avez pas à interrompre le service des données pour effectuer des mises à jours de code, contrairement au monde applicatif, dans lequel la commande ALTER n'existe pas... Dans le monde applicatif, vous êtes obligé d'arrêter l'applicatif pour les mises à jours de version et donc, vous devez couper tous les utilisateurs....

A +

[JPLAROCHE]

Cela dépend de deux facteurs :
A +

Bonjour, un grand merci pour avoir pris le soin de me répondre.


Je vais prendre soin de lire correctement l'article que vous me suggérez.

Tout viens que j'ai terminé une grosse partie de mes outils sur nim-lang. Alors je voulais mettre aussi en œuvre une base de donné offert sur PostgreSQL très propre et avec son tutoriel, il y a les procédures stockées,
venant du monde IBM je n'utilisais pas cela, sql oui mais pas les procédures stockées.

je vais regarder tout ça.

Pour les verrous sur IBM DB2 OS400(IPOWER) on peut signaler à l'utilisateur que l'enregistrement est occupé par tels ou tels personnes en entreprise, cela enlevait des ambiguïtés. Car il peut s'avérer obligatoire dans une application de poser des verrous.
Bon l'Ipower est une machine dédier à la gestion d'entreprise...

je reviendrais pour vous poser d'autre question s'il y a lieu sur ce sujet après ma lecture.

il est vrai que dans la solution 1) les allées retour son moins nombreux.

[SQLpro]

...
Pour les verrous sur IBM DB2 OS400(IPOWER) on peut signaler à l'utilisateur que l'enregistrement est occupé par tels ou tels personnes en entreprise, cela enlevait des ambiguïtés. Car il peut s'avérer obligatoire dans une application de poser des verrous.
Bon l'Ipower est une machine dédier à la gestion d'entreprise....

Ce n'est pas du tout réaliste dans :
1) le monde du client serveur
2) les bases de données à fort accès concurrentiel

Prenons un exemple simple, celui du site de réservation SNCF.com.
Vous avez trouvé votre TGV, sélectionné une place.
Rien ne permet de vous garantir que votre choix ne soit pas pris par quelqu'un d'autre qui va aller plus vite...
Si vous pouviez bloquer la place, imaginez maintenant que tant Ursuline que vous n'avez pas vu depuis vingt ans vous téléphone et commence par vous raconter sas vie en Nouvelle Zélande.... Et si tout le monde faisait comme cela, la SNCF serait ruinée !
Même lorsque vous devez payer la situation n'est pas bloquée définitivement. Vous pouvez alors avoir une annulation de la transaction......

A +

[JPLAROCHE]

D'accord mais par exemple pour la production vous ne pouvez pas constamment remette en cause la quantité à fabriquer, car la commande fournisseur par exemple pour du papier etc... Après bien-sur vous pouvez faire un avenant si l'usine n'a pas tourné en production. Mais là je suis bien en interne dans l'entreprise et non pas sur le web

sur le web il n'y avait pas de blocage pour les commandes car nos clients avaient signé une charte 24h pour annulation après oups .... Pour eux aussi on avait aussi des contraintes dans l'autre sens.
Mais parfois avec le tel. On accélérait et là le blocage se faisait par la livraison(seulement) mais ce sont des exceptions(en dehors de solder la commande). Mais ce n'était pas un vrai blocage juste une impossibilité de modifier dans ce cas.(un message ré étirer)

Exemple*: 3 gros clients répartit sur plus de 2500 accès. Le flux était minime 1à2 ko de data une fois connecté, Apache mode IBM
la vitesse de la machine est de moins de 3 nano-secondes pour le traitement ,la sortie en G bytes , je n'ai jamais eu de blocage, les lignes sont encore pas à ce niveau(on ne travaillait pas au niveau bancaire sniffer). J'avais 40 postes réels en concurrence et dans les statistiques je n'ai que rarement atteint les 15 postes le flux d'internet standards ou les serveurs de carrefour/renault/fnac par exemple la réponse leur était faite qu'eux n'avaient pas encore le résultat. Test à l'appui. Pourtant on était prêt à augmenter le nombre de postes concurrents la machine était taillée pour
le temps acceptable est entre 1à2 secondes pour l'utilisateur avant on n'arrivait pas à descendre en dessous de 5s le temps physique de réponse des écrans pas de la machine, pour l'humain le temps n'est pas le temps machine

j'en reviens au blocage effectivement pour 2) les bases de données à fort accès concurrentiel on ne peut raisonner en termes de bocage (RÉEL)

cette discussion était en prévision de travail ou de solution interactive synchrone

Dans tous les cas je vous remercie d'avoir pris du temps pour me répondre (très intéressant)
je pense que l'on est d'accords.