Consultez la FAQ sur le ZF avant de poster une question
Vous n'êtes pas identifié.
Bonjour à tous
En me réveillant ce matin j'ai pensé à un truc qui me titille depuis et donc j'ai jamais poussé la recherche plus loin. enfin c'est plutôt une question à savoir les avantages d'une utilisation des transactions plutôt que des requêtes normales pour des enregistrements dans un sgbd.
en regardant vite fait j'ai decourvert ceci
"les transactions rendent vos scripts plus rapides et potentiellement plus robuste", ok mais un peu too much pour moi.
alors la questions s'adresse à ceux qui l'utilisent et les conclusions qu'ils en tirent, merci
bien cordialement
Hors ligne
Bonjour,
Les transactions représentent un énorme intérêt, à condition d'avoir à effectuer plusieurs requêtes pour une seule action de l'application.
Je vais prendre un exemple, ce sera plus parlant.
Imagine un formulaire pour ajouter un utilisateur à une application contenant plusieurs modules, il se peut qu'un utilisateur puisse avoir accéder à certains modules et à d'autres non. En SQL, cela se traduit par un insert dans la table des utilisateurs, et à un ou plusieurs insert dans la table liant les modules aux utilisateurs.
En gros tu vas avoir çà :
1 -INSERT INTO tb_utilsateurs SET ... (info user) 2- INSERT INTO tb_droits SET ... (accès module 1) 3- INSERT INTO tb_droits SET ... (accès module 2) 4- INSERT INTO tb_droits SET ... (accès module 3)
Imagine maintenant que pour une raison X, ta requête 3 plante, ca arrête tout, la requête 4 n'est jamais exécuté et tu te retrouves avec un utilisateur à moitié créé. our éviter celà, tu vas mettre des contrôles de tous les côtés pour faire en sorte que si une requête plante, tu vas supprimer tout ce que tu as insérer avant, bref un travail aussi pénible qu'inefficace (imagine ton delete qui déconne ...).
En gros, c'est là qu'interviennent les transactions SQL, tu vas oucrir une transaction avant ta première requête et valider toutes tes requêtes une fois la dernière (et les précédentes) exécutée correctement. Si un problème intervient sur une requête du processus, tu pourras alors revenir en arrière au niveau SQL, et annuler d'un coup toutes les requêtes que tu as envoyés depuis le début de ta transaction.
Avec la gestion des transactions de Zend_Db, il te suffit d'intercepeter les exceptions de chacune de tes requêtes et de faire un "rollback" si une est repérée pour que toutes tes requêtes s'annuelent automatiquement.
Dans l'exemple précédent, une erreur sur la requête 3, un simple rollback annulera tout seul tes requêtes 1 et 2 si elles font parties de la transaction.
Voilà une explication bien faite sur les transactions : http://www.siteduzero.com/tutoriel-3-16 … -pdo.html.
Voilà la doc qui explique comment faire en Zend_DB : http://zendframework.com/manual/fr/zend.db.adapter.html
J'espère t(avoir aidé à comprendre l'intérêt
Bon courage
Hors ligne
Tu utilisera les transactions naturellement quand tu aura besoin de cloisonner les choses...
Il s'agit comme l'a expliqué Geoffrey de lancer un "commit" sur la base de donnée, lorsque X requêtes sont passées avec succès, sinon un "rollback".
Les transactions sont souvent utilisés dans le monde financier.
Hors ligne
Bonjour ,
merci Geoffrey et armetiz pour ces informations je comprend mieux l'intérêt des transactions. En gros il est plus utile de les réaliser pour des grosses applications et non pour des sites avec une dizaine de tables
Hors ligne
yveson33 a écrit:
En gros il est plus utile de les réaliser pour des grosses applications et non pour des sites avec une dizaine de tables
Pas nécessairement, perso je m'en sers même pour de petits projets, mais où un script doit écrire dans plusieurs tables pour enregistrer ce qu'il y a dans un seul formulaire validé.
Hors ligne