par
Tracker » 22 oct. 2007, 08:42
Je n'ai pas dit que c'était simple. Encore que pour l'intégrité référentielle par programmation, ce n'est pas vraiment sorcier : il faut maîtriser son modèle et veiller à procéder aux vérifications soi-même avant de modifier ou supprimer une donnée.
On est dans un environnement multisession, et donc c'est pas aussi simpliste. Tu as beau faire tous les tests que tu veux, si tu ne lockes pas les structures, tu n'empêcheras personne d'intercaler une modif rendant ta vérification désuette, et donc le traitement en dépendant incohérent.
Pour les transactions, c'est effectivement une autre paire de manches. Pas impossible mais techniquement faisable : un des intérêts de la transaction, c'est le "commit/rollback" : par programmation, ça voudrait dire enregistrer chacune des requêtes effectuées dans la transaction, générer chaque requête inverse et en cas de besoin d'un rollback, exécuter ces requêtes inversant les actions pour remettre la base en l'état.
Pareil, si tu as une erreur lors de l'execution du rollback (comme par exemple recréer un enregistrement pointant vers un autre (FK) qui a entre temps été supprimé par une autre connexion), ta base doit-être dans quel état ? d'autant que, sans lock, d'autres connexions ont pu faire des modifs sur les mêmes données qui seraient purement écrasées par ton rollback, bonjour l'intégrité des infos...
Tu as beau prendre le problème dans tous les sens, de façon programmative il est impossible de gérer la transactionnalité. Le contrôle de références par contre est envisageable mais au prix de verrouillages globaux en mode MyISAM.
[edit]
Les principes de gestion, que tu proposes, sous-entendent, pour être pertinents, qu'une seule connexion modifie les infos. Tu te places implicitement dans une mode de fonctionnement mono-utilisateur en modification et multi-utilisateur en visualisation.
Tracker.
[quote="Cyrano"]Je n'ai pas dit que c'était simple. Encore que pour l'intégrité référentielle par programmation, ce n'est pas vraiment sorcier : il faut maîtriser son modèle et veiller à procéder aux vérifications soi-même avant de modifier ou supprimer une donnée.
[/quote]
On est dans un environnement multisession, et donc c'est pas aussi simpliste. Tu as beau faire tous les tests que tu veux, si tu ne lockes pas les structures, tu n'empêcheras personne d'intercaler une modif rendant ta vérification désuette, et donc le traitement en dépendant incohérent.
[quote="Cyrano"]Pour les transactions, c'est effectivement une autre paire de manches. Pas impossible mais techniquement faisable : un des intérêts de la transaction, c'est le "commit/rollback" : par programmation, ça voudrait dire enregistrer chacune des requêtes effectuées dans la transaction, générer chaque requête inverse et en cas de besoin d'un rollback, exécuter ces requêtes inversant les actions pour remettre la base en l'état.[/quote]
Pareil, si tu as une erreur lors de l'execution du rollback (comme par exemple recréer un enregistrement pointant vers un autre (FK) qui a entre temps été supprimé par une autre connexion), ta base doit-être dans quel état ? d'autant que, sans lock, d'autres connexions ont pu faire des modifs sur les mêmes données qui seraient purement écrasées par ton rollback, bonjour l'intégrité des infos...
Tu as beau prendre le problème dans tous les sens, de façon programmative il est impossible de gérer la transactionnalité. Le contrôle de références par contre est envisageable mais au prix de verrouillages globaux en mode MyISAM.
[edit]
Les principes de gestion, que tu proposes, sous-entendent, pour être pertinents, qu'une seule connexion modifie les infos. Tu te places implicitement dans une mode de fonctionnement mono-utilisateur en modification et multi-utilisateur en visualisation.
Tracker.
