Selon une concurrence élevée, la contrainte de clé étrangère de la base de données devrait-elle être utilisée?

Compromis sur les contraintes de clés étrangères de la base de données dans des scénarios de concurrence élevés

Dans des projets qui poursuivent des performances de concurrence élevées, une question controversée est souvent rencontrée: est-il nécessaire d'utiliser des contraintes de clés étrangères dans la base de données? Certaines personnes disent que pour améliorer l'efficacité, les clés étrangères doivent être interdites. Que se passe-t-il?

En fait, dans certains scénarios de concurrence élevés, il est en effet nécessaire de choisir de ne pas utiliser les contraintes de clés étrangères physiques fournies par la base de données. Cela ne signifie pas que le concept de clés étrangères a été complètement abandonné, mais plutôt qu'il évite de s'appuyer sur les caractéristiques des clés étrangères fournies par la base de données elle-même pour garantir la cohérence des données. La raison en est que les contraintes de clés étrangères au niveau de la base de données affecteront les performances de l'opération d'écriture de la base de données, en particulier dans les environnements de concurrence élevés, l'inspection des clés étrangères deviendra un goulot d'étranglement des performances.

Donc, si les clés étrangères physiques ne sont pas utilisées, comment la cohérence des données peut-elle être garantie? La réponse est: elle est mise en œuvre via la couche commerciale. Par exemple, lorsque les données de la table principale sont supprimées, les enregistrements correspondants dans le tableau d'association doivent également être supprimés. L'utilisation de clés étrangères physiques peut être facilement mise en œuvre par délétion en cascade, mais si les clés étrangères physiques sont désactivées, vous devez écrire explicitement du code sur la couche logique métier pour supprimer le tableau principal et le tableau associé respectivement. De même, le fonctionnement de mise à jour des contraintes de clés étrangères doit également être traité sur la couche commerciale.

De cette façon, l'atomicité des opérations de base de données est transférée de la couche de base de données vers la couche d'application. La couche d'application doit assurer l'atomicité des opérations et nécessite généralement un mécanisme de transaction pour assurer l'intégrité des données.

Il convient de noter que dans de nombreux scénarios de concurrence élevés, la cohérence ultime suffit. Cela signifie que la cohérence des données ne doit pas être strictement tenue d'être terminée en même temps, permettant une courte fenêtre de temps, et les données peuvent être dans un état incohérent, mais finiront par atteindre la cohérence. Ceci est différent d'une cohérence forte (les données doivent être cohérentes à tout moment). La cohérence ultime peut mieux s'adapter à des environnements de concurrence élevés et améliorer le débit du système. Par conséquent, l'abandon des clés étrangères physiques de la base de données et être responsable de la cohérence des données est une solution réalisable dans de nombreux scénarios de concurrence élevés.

Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!