Imaginez une telle scène. Par exemple, une table de test contient des champs
count:0
name:'abc'
Lorsque l'utilisateur ouvre une interface d'édition, les données lues dans la base de données sont
count:3
name:'abc'
Puis il a changé de nom et c'est devenu comme ça
count:3
name:'efg'
En ce moment, d'autres programmes lisent et écrivent cette table de test à grande vitesse. Étant donné que l'utilisateur n'a pas enregistré les données dans la table de données, les données enregistrées par d'autres programmes sont
count:40
name:'abc'
Modifiez continuellement le champ de comptage en 41, 42, 43. À ce stade, l'utilisateur a terminé la modification et enregistré les données dans la base de données. Les données finales enregistrées à ce moment sont
.count:3
name:'efg'
Ensuite, le problème se pose. . . Il y a un problème avec les données du champ de comptage.
Comment résoudre ce problème ?
1. Soit séparez le champ de comptage dans une autre table, puis associez les deux tables sans interférer l'une avec l'autre. Cependant, lors de la lecture des données de cette manière, deux tableaux doivent être lus, ce qui est un peu gênant.
2. Lorsque les utilisateurs enregistrent des données, mettez à jour uniquement les champs nécessaires. Par exemple, le champ count lit l'ancien dans la base de données. Cependant, lorsque la table de données comporte des dizaines de champs, la procédure est un peu lourde.
Comment l'avez-vous résolu ?
Problèmes de transaction typiques.
Quelle base de données utilisez-vous ? Avez-vous étudié le commerce ? Découvrez comment la base de données que vous utilisez prend en charge les transactions.
Pour faire simple : verrouillez les données afin qu'un seul client puisse effectuer des opérations de lecture et d'écriture en même temps, et que les autres clients doivent attendre.