Cela ne peut pas fonctionner ainsi. Considérez :
- programme un, vous ouvrez une transaction et insérez dans une table FOO qui a une clé primaire autoinc (arbitrairement, nous disons qu'il obtient 557 pour sa valeur de clé).
- Le programme deux démarre, il ouvre une transaction et l'insère dans la table FOO en obtenant 558.
- Programmer deux insertions dans la table BAR qui a une colonne qui est une clé étrangère à FOO. Alors maintenant, le 558 est situé à la fois dans FOO et BAR.
- Le programme 2 est maintenant validé.
- Le programme trois démarre et génère un rapport à partir de la table FOO. L'enregistrement 558 est imprimé.
- Après cela, le programme 1 revient en arrière.
Comment la base de données récupère-t-elle la valeur 557 ? Va-t-il dans FOO et décrémente-t-il toutes les autres clés primaires supérieures à 557 ? Comment répare-t-il BAR ? Comment efface-t-il le 558 imprimé sur la sortie du programme de rapport trois ?
Les numéros de séquence d'Oracle sont également indépendants des transactions pour la même raison.
Si vous pouvez résoudre ce problème en temps constant, je suis sûr que vous pouvez gagner beaucoup d'argent dans le domaine de la base de données.
Maintenant, si vous avez une exigence que votre champ d'incrémentation automatique n'ait jamais d'espace (à des fins d'audit, par exemple). Ensuite, vous ne pouvez pas annuler vos transactions. Au lieu de cela, vous devez avoir un indicateur de statut sur vos enregistrements. Lors de la première insertion, le statut de l'enregistrement est "Incomplet", puis vous démarrez la transaction, faites votre travail et mettez à jour le statut pour "concourir" (ou tout ce dont vous avez besoin). Ensuite, lorsque vous vous engagez, l'enregistrement est en direct. Si la transaction est annulée, l'enregistrement incomplet est toujours là pour l'audit. Cela vous causera bien d'autres maux de tête, mais c'est une façon de gérer les pistes d'audit.
