Considérations sur les performances pour les déclencheurs et les contraintes

Question

J'essaie de savoir si je devrais utiliser la logique critique de l'entreprise dans un déclencheur ou une contrainte à l'intérieur de ma base de données.
Jusqu'à présent, j'ai ajouté une logique dans les déclencheurs, car cela me permet de contrôler ce qui se passe ensuite et signifie que je peux fournir des messages utilisateur personnalisés à la place d'une erreur susceptible de dérouter les utilisateurs.

Existe-t-il un gain de performance notable en utilisant des contraintes sur les déclencheurs et quelles sont les meilleures pratiques pour déterminer lequel utiliser.

Answer 1

Les contraintes haut la main!

• Avec des contraintes, vous spécifiez des principes relationnels, c’est-à-dire des faits concernant vos données. Vous n’aurez jamais besoin de changer vos contraintes, à moins que certains faits ne changent (par exemple de nouvelles exigences).

• Avec les déclencheurs, vous indiquez comment gérer les données (dans les insertions, les mises à jour, etc.). Ceci est un "quotient non relationnel" manière de faire les choses.

Pour mieux m'expliquer par une analogie: la meilleure façon d'écrire une requête SQL est de spécifier "ce que vous voulez". au lieu de "comment l'obtenir" - laissez le SGBDR trouver le meilleur moyen de le faire pour vous. La même chose s’applique ici: si vous utilisez des déclencheurs, vous devez garder à l’esprit diverses choses telles que l’ordre d’exécution, la cascade, etc. Laissez le SQL le faire pour vous avec des contraintes si possible.

Cela ne veut pas dire que les déclencheurs n’ont pas d’utilisation. Ils le font: parfois, vous ne pouvez pas utiliser une contrainte pour spécifier certains faits à propos de vos données. C'est extrêmement rare cependant. Si cela vous arrive beaucoup , il y a probablement un problème avec le schéma.

Answer 2

Meilleures pratiques : si vous pouvez le faire avec une contrainte, utilisez une contrainte.

Les déclencheurs ne sont pas aussi mauvais qu'ils obtiennent un discrédit (s'ils sont utilisés correctement), bien que j'utilise toujours une contrainte autant que possible. Dans un SGBD moderne, les performances des déclencheurs sont comparables aux contraintes (cela ne signifie bien sûr pas que quelqu'un ne peut pas placer un code épouvantable dans un déclencheur!).

Il est parfois nécessaire d'utiliser un déclencheur pour appliquer une contrainte "complexe" telle que le fait de vouloir imposer qu'un et un seul des deux champs de clé étrangère d'une table soient renseignés (j'ai vu cette situation dans quelques domaines modèles).

Le débat sur la question de savoir si la logique applicative doit résider dans l'application plutôt que dans la base de données dépend dans une certaine mesure de l'environnement; Si de nombreuses applications accèdent à la base de données, les contraintes et les déclencheurs peuvent servir de dernier garde à l’exactitude des données.

Answer 3

Les déclencheurs peuvent devenir un problème de performances. À peu près au même moment, ils sont également devenus un cauchemar d’entretien. Vous ne pouvez pas savoir ce qui se passe et (bonus!), L'application se comporte de manière erratique avec le mot clé "faux". problèmes de données. [Vraiment, ce sont des problèmes déclencheurs.]

Aucun utilisateur final ne touche SQL directement. Ils utilisent des programmes d'application. Les programmes d'application contiennent une logique métier de manière beaucoup plus intelligente et plus facile à gérer que des déclencheurs. Placez la logique d'application dans les programmes d'application. Placez les données dans la base de données.

Sauf si vous et vos "utilisateurs" ne partagez pas un langage commun, vous pouvez leur expliquer les violations de contrainte. L’alternative - ne pas expliquer - transforme une simple base de données en problème, car elle confond les données et le code de l’application en un bourbier impossible à maintenir.

"Comment puis-je être absolument certain que tout le monde utilise correctement le modèle de données?"

Deux (et demi) techniques.

1. Assurez-vous que le modèle est correct : il correspond au domaine du problème réel. Pas de hacks, de solutions de contournement ou de raccourcis qui ne peuvent être résolus que par le biais d'explications complexes, de procédures stockées et de déclencheurs.

2. aide à définir la couche de modèle d'entreprise des applications. La couche de code d'application que tout le monde partage et réutilise.

   a. Assurez-vous également que la couche de modèle répond aux besoins des utilisateurs. Si la couche de modèle dispose des méthodes et des collections appropriées, vous serez moins incité à la contourner pour obtenir un accès direct aux données sous-jacentes. Généralement, si le modèle est correct, il ne s’agit pas d’une préoccupation profonde.

Les déclencheurs sont une épave de train sur le point d’arriver. Les contraintes ne sont pas.

Answer 4

Outre les autres raisons d'utiliser des contraintes, l'optimiseur Oracle peut utiliser les contraintes à son avantage.

Par exemple, si vous avez une contrainte indiquant (Montant > = 0) , puis vous interrogez avec WHERE (Montant = -5) , Oracle sait immédiatement qu'il existe ne correspond à aucune ligne.

Answer 5

Les contraintes et les déclencheurs s'appliquent à 2 choses différentes. Les contraintes sont utilisées pour contraindre le domaine (entrées valides) de vos données. Par exemple, un SSN serait stocké sous la forme char (9), mais avec une contrainte de [0-9] [0-9] [0-9] [0-9] [0-9] [0-9] [ 0-9] [0-9] [0-9] (entièrement numérique).

Les déclencheurs permettent d’appliquer la logique d’entreprise dans votre base de données. Si nous reprenons le SSN, il faudra peut-être conserver une piste d’audit chaque fois qu’un changement de SSN sera modifié - cela se ferait avec un déclencheur,

En général, les problèmes d'intégrité des données dans un SGBDR moderne peuvent être traités avec certaines variantes d'une contrainte. Cependant, vous vous retrouverez parfois dans une situation où une normalisation incorrecte (ou des exigences modifiées entraînant une normalisation incorrecte) empêche une contrainte. Dans ce cas, un déclencheur peut peut-être appliquer votre contrainte - mais elle est opaque pour le SGBDR, ce qui signifie qu'elle ne peut pas être utilisée pour l'optimisation. C'est aussi "masqué". logique, et peut être un problème de maintenance. Décider de refactoriser le schéma ou d’utiliser un déclencheur est un appel de jugement à ce stade.

Answer 6

De manière générale, je préférerais les contraintes et mon code intercepterait les erreurs de serveur SQL et présenterait quelque chose de plus convivial pour l'utilisateur.

Answer 7

@onedaywhen

Vous pouvez utiliser une requête en tant que contrainte dans SQL Server, il vous suffit simplement de pouvoir l'adapter à une fonction scalaire: http://www.eggheadcafe.com/software/aspnet/30056435/check-contraints-and-tsql.aspx

Answer 8

@Mark Brackett: "Les contraintes sont utilisées pour contraindre le domaine ... Les déclencheurs sont un moyen d'appliquer la logique métier": ce n'est pas si simple dans SQL Server, car la fonctionnalité de ses contraintes est limitée, par exemple. pas encore complet SQL-92. Prenons l'exemple classique d'une «clé primaire» séquencée dans une table de base de données temporelle: idéalement, j'utiliserais une contrainte CHECK avec une sous-requête pour éviter le chevauchement des périodes pour la même entité, mais SQL Server ne peut pas le faire. déclencheur. La capacité de SQL-92 de différer la vérification des contraintes est également absente de SQL Server. Celles-ci sont plutôt vérifiées après chaque instruction SQL. Un déclencheur peut donc être nécessaire pour contourner les limitations de SQL Server.

Answer 9

Si possible, utilisez des contraintes. Ils ont tendance à être un peu plus vite. Les déclencheurs doivent être utilisés pour la logique complexe qu'une contrainte ne peut pas gérer. L’écriture de déclencheur est également délicate et si vous vous trouvez obligé d’écrire un déclencheur, veillez à utiliser des instructions basées sur les ensembles, car les triigers agissent sur l’ensemble des opérations d’insertion, de mise à jour ou de suppression (oui, dans certains cas, plusieurs enregistrements sont affectés, planifiez sur cela!), pas seulement un enregistrement à la fois. N'utilisez pas de curseur dans un déclencheur s'il peut être évité.

Dans la mesure où il convient de placer la logique dans l'application au lieu d'un déclencheur ou d'une contrainte. NE FAITES PAS CELA!!! Oui, les applications doivent avoir des contrôles avant d’envoyer les données, mais l’intégrité des données et la logique commerciale doivent se situer au niveau de la base de données, sinon vos données seront brouillées lorsque plusieurs applications y sont connectées, lorsque des insertions globales sont effectuées en dehors de l’application, etc. L’intégrité est la clé des bases de données et doit être appliquée au niveau de la base de données.

Answer 10

@Meff: l'utilisation d'une fonction peut poser des problèmes car, tout simplement, les contraintes SQL Server CHECK ont été conçues avec une seule ligne comme unité de travail et présentent des défauts lors de l'utilisation d'un jeu de résultats. Pour plus de détails à ce sujet, voir: [ http://blogs.conchango.com/davidportas/archive/2007/02/19/Trouble-with-CHECK-Constraints.aspx] [1] .

[1]: Blog de David Portas: Problèmes avec les contraintes de vérification.

Answer 11

Identique à Skliwz. Pour vous informer de l’utilisation canonique du déclencheur , sa table d’audit. Si de nombreuses procédures mettent à jour / insèrent / suppriment une table à auditer (qui a modifié quoi et quand), trigger est la méthode la plus simple. Une solution consiste simplement à ajouter un indicateur dans votre table (actif / inactif avec une contrainte d'unicité) et à insérer quelque chose dans la table d'audit.

Si vous souhaitez que la table ne conserve pas les données historiques, vous pouvez également copier l'ancienne ligne de votre table d'audit ...

Beaucoup de gens ont plusieurs façons de le faire. Mais une chose est sûre, vous devrez effectuer une insertion pour chaque mise à jour / insertion / suppression de ce tableau

Pour éviter d’insérer l’insert dans une douzaine d’endroits différents, vous pouvez utiliser ici un déclencheur.

Answer 12

Je suis d’accord avec tout le monde ici sur les contraintes. Utilisez-les autant que possible.

Il existe une tendance à abuser des déclencheurs, en particulier avec les nouveaux développeurs. J'ai vu des situations dans lesquelles un déclencheur déclenche un autre déclencheur, qui en déclenche un autre qui répète le premier, créant ainsi un déclencheur en cascade qui bloque votre serveur. Ceci est un utilisateur non optimal de déclencheurs; o)

Cela étant dit, les déclencheurs ont leur place et doivent être utilisés le cas échéant. Ils sont particulièrement utiles pour suivre les modifications des données (comme Mark Brackett l’a mentionné). Vous devez répondre à la question "Où est-il le plus logique de mettre ma logique métier"? La plupart du temps, je pense que cela fait partie du code, mais vous devez garder l'esprit ouvert.