J'ai quelques tables où des contraintes de clés étrangères sont ajoutées. Ceux-ci sont utilisés avec la génération de code pour configurer des jointures spécifiques dans des procédures stockées générées.
est-il possible de remplacer ces contraintes en appelant plusieurs suppresses dans une transaction, en particulier "transactionsCope" en C # ou en cascade supprime absolument nécessaire?
5 Réponses :
Vous ne pouvez pas remplacer les contraintes FK, si vous pouviez savoir quel serait le point de les créer en premier lieu?
Vrai, ce que je veux dire, c'est que: Est-ce que la contrainte / références de la clé étrangère ne serait-elle pas validée / vérifiée sur les lignes jusqu'à la fin de la transaction afin que les suppressions en cascade n'auraient pas besoin de faire.
Je ne le crois pas; Même à l'intérieur d'une transaction, l'intégrité relationnelle est appliquée. Vous pouvez désactiver les points de la FK comme OMG.
C'est une pitié de l'intégrité n'est pas chèque à la fin d'une transaction (ou activée / configurée de le faire), cela aiderait.
Le seul moyen de "remplacer" un contrainte de clé étrangère est Pour le désactiver:
La désactivation d'une contrainte de clé étrangère permet de modifier les données dans le tableau sans être validées par les contraintes. Désactivez une contrainte de clé étrangère lors des instructions d'insertion et de mise à jour si de nouvelles données violeront la contrainte ou si la contrainte doit s'appliquer uniquement aux données déjà dans la base de données. p> blockQuote>
Vous devez utiliser la commande
alter Table code> pour désactiver une contrainte, à l'aide du mot-clé code> nocheck code>. IE: P>ALTER TABLE dbo.cnst_example NOCHECK CONSTRAINT salary_cap;
+1, exactement ce que je pensais, si le FK n'existe que pour une utilité générale de code pour effectuer certaines procédures stockées, puis les déposer ne serait pas vraiment un problème alors.
KM: Nous faisons du code Gen beaucoup, supprimez généralement les contraintes pour les bases de données de production et supprimez également tous les enregistrements. Les contraintes ne sont donc généralement pas une question. Dans un nouveau modèle multi-location, nous pensions à les garder, mais supprimez tout un locataire, qui est nécessaire, nous donne cette question clé étrangère. Je préférerais ne pas désactiver / activer ou déposer / créer les contraintes. Je suppose que nous pourrions que nous puissions connaître l'ordre des suppressions (qui ressemblent à un choix évident, ou nous ne pouvons tout simplement pas utiliser les contraintes que vous le mentionnez.
@Mark Redman: L'intégrité des données est très discutable s'il n'y a aucune contrainte en place.
Cela dépend de quoi d'autre s'occupe de l'intégrité, mais généralement oui, je suis d'accord.
Ne pas utiliser Cascade Suppr, vous pouvez causer des problèmes de performance graves de cette façon. La meilleure procédure consiste à faire les suppresses dans l'ordre de la table enfant la plus basse jusqu'à la table des parents.
La désactivation des clés étrangères est une ordonnance pour avoir des problèmes d'intégrité des données. La seule fois où quelque chose comme ça devrait être fait est d'un DBA qui est extrêmement expérimenté et bien conscient des problèmes qui pourraient causer. Si vous posez cette question, vous n'êtes pas encore suffisamment expérimenté pour utiliser cette technique. N'oubliez pas que lorsque vous désactivez le FK, vous le désactivez pour tout le monde, pas seulement votre processus.
OP dit: ... Les contraintes de clé étrangère sont ajoutées. Ceux-ci sont utilisés avec la génération de code pour configurer des jointures spécifiques dans des procédures stockées générées.
@Hlgem: Je conviens que dans cette situation (décrit dans l'un de mes commentaires sur une autre réponse), la suppression satinable de l'ordre du plus bas est probablement la meilleure option.
Je ne suis pas d'accord que la cascade supprime causer un problème de performance. En fait, ils sont la solution la plus efficace possible (examinez le plan d'exécution). Si vous le faites manuellement, vous devez effectuer la même quantité de travail mais plus inefficace.
Si vos contraintes FK sont spécifiquement définies pour une utilisation spécifique dans les procédures stockées, elles ne sont pas
Ils sont utilisés pour configurer certaines jointures dans la génération de code (sélectionnant etc.), mais fonctionnent comme conçues si FKS est laissée dans.
Les contraintes peuvent être définies sur immédiate ou retardées à la fin d'une transaction. Le retardement à la fin d'une transaction vous permet de violer les contraintes pendant que vous construisez la transaction, mais faites-les appliquer à la fin de la transaction. D'après ce que je comprends, retarder jusqu'à la fin d'une transaction est ce que vous êtes probablement après.