Considérations sur les performances des Déclencheurs vs Contraintes
J'essaie de savoir si je dois être à l'aide de critiques de la logique dans un déclencheur ou une contrainte à l'intérieur de ma base de données.
Jusqu'à présent, j'ai ajouté de la logique dans les déclencheurs comme il me donne le contrôle sur ce qui se passe à côté et je peux fournir des messages de l'utilisateur au lieu d'une erreur qui sera probablement confondre les utilisateurs.
Est-il notable gain de performance en utilisant des contraintes sur les déclencheurs et quelles sont les meilleures pratiques pour la détermination de l'utiliser.
- envisager de prendre loin de sql server tous les renvois. Je pense que la question et les réponses sont à la base de données agnostique.
Vous devez vous connecter pour publier un commentaire.
Contraintes les mains!
Avec les contraintes que vous spécifiez relationnel principes, c'est à dire des faits à propos de vos données. Vous n'aurez plus jamais besoin de changer vos contraintes, à moins que des changements (nouveaux besoins).
Avec des déclencheurs vous de spécifier comment traiter les données (dans les insertions, mises à jour etc.). C'est un "non-relationnelle" façon de faire les choses.
À m'expliquer mieux avec une analogie: la bonne façon d'écrire une requête SQL est à préciser "ce que vous voulez" au lieu de "comment faire" – laissez-le SGBDR de déterminer la meilleure façon de le faire pour vous. La même chose s'applique ici: si vous utilisez des déclencheurs, vous devez garder à l'esprit différentes choses comme l'ordre de l'exécution, en cascade, etc... Laissez-SQL le faire pour vous avec les contraintes si possible.
Qui ne veut pas dire que les déclencheurs n'ont pas utilise. Ils n': parfois, vous ne pouvez pas utiliser une contrainte de préciser certains faits au sujet de vos données. Il est extrêmement rare que. Si cela vous arrive beaucoup, puis il ya probablement un problème avec le schéma.
Meilleures Pratiques: si vous pouvez le faire avec une contrainte, l'utilisation d'une contrainte.
Les déclencheurs ne sont pas tout à fait aussi mauvais qu'ils se discréditer (si utilisé correctement), bien que je serais toujours utiliser une contrainte dans la mesure du possible. Dans un cadre moderne RDMS, la charge de travail des déclencheurs est comparable à des contraintes (bien sûr, cela ne veut pas dire que l'on ne peut pas placer d'horribles code dans un déclencheur!).
Parfois il est nécessaire d'utiliser un déclencheur pour imposer un "complexe" de contrainte comme la situation de vouloir appliquer qu'à un seul d'une Table de deux champs de clé Étrangère sont peuplées (j'ai vu cette situation de quelques modèles de domaine).
Le débat de savoir si la logique d'entreprise doit résider dans l'application plutôt que de la DB, dépend dans une certaine mesure sur l'environnement; si vous avez beaucoup d'applications qui accèdent à la base de données, à la fois des contraintes et des déclencheurs peuvent servir de final de la garde que les données sont correctes.
CHECK (ColA is null and ColB is not null or ColA is not null and ColB is null)Déclencheurs peuvent s'épanouir dans un problème de performance. Vers la même époque que se passe ils sont aussi devenus un entretien cauchemar. Vous ne pouvez pas comprendre ce qui se passe et (bonus!) l'application se comporte de façon erratique, avec des "fausses" problèmes de données. [Vraiment, ils sont de provoquer des problèmes.]
Pas de fin-utilisateur touche SQL directement. Ils utilisent des programmes d'application. Les programmes d'Application contiennent la logique métier dans un cadre beaucoup plus intelligemment et de façon plus prévisible que les déclencheurs. L'application de la logique dans les programmes d'application. Mettre les données dans la base de données.
À moins que vous et votre "utilisateurs" ne pas partager un langage commun, vous pouvez expliquer les violations de contrainte pour eux. L'alternative, ne pas expliquer -- fait d'une simple base de données dans un problème, car il regroupe les données et le code d'application dans un désuète bourbier.
"Comment puis-je obtenir l'assurance absolue que tout le monde en utilisant le modèle de données correctement?"
Deux (et demi) techniques.
Assurez-vous que le modèle est droit: il correspond à la réalité du monde du domaine du problème. Pas de hacks ou une solution de contournement ou des raccourcis qui ne peuvent être réglés par une complexe à la main en agitant des explications, des procédures stockées et des triggers.
Aider à définir le modèle d'affaires de la couche des applications. La couche de code de l'application que tout le monde partage et la réutilisation.
un. Aussi, assurez-vous que la couche de modèle répond aux besoins de la population. Si le modèle de la couche a le droit de méthodes et de collections, il y a moins d'incitation à contourner pour obtenir un accès direct aux données sous-jacentes. Généralement, si le modèle est bon, ce n'est pas une profonde préoccupation.
Déclencheurs sont un train-épave en attente de se produire. Les contraintes ne sont pas.
En plus d'autres raisons d'utiliser les contraintes, l'optimiseur Oracle peut utiliser des contraintes à son avantage.
Par exemple, si vous avez une contrainte de dire
(Amount >= 0)et ensuite vous interroger avecWHERE (Amount = -5)Oracle sait immédiatement qu'il n'existe pas de lignes correspondantes.Contraintes et les déclencheurs sont 2 choses différentes. Les contraintes sont utilisées pour contraindre le domaine (les entrées valides) de vos données. Par exemple, un SSN est stockée en tant que 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] (tous numériques).
Déclencheurs sont un moyen de faire respecter des affaires logique dans votre base de données. La prise de SSN, à nouveau, peut-être une piste d'audit doit être maintenu à chaque fois qu'un numéro de sécurité sociale est modifié - qui serait fait avec un seuil de déclenchement,
En général, les problèmes d'intégrité des données dans un cadre moderne SGBDR peuvent être traitées avec une certaine variation d'une contrainte. Cependant, vous aurez parfois retrouver dans une situation où une mauvaise normalisation (ou les besoins de changement, résultant en maintenant une mauvaise normalisation) empêche une contrainte. Dans ce cas, un déclencheur peut être en mesure de faire respecter vos contraintes, mais il est opaque pour le SGBDR, le sens qu'il ne peut pas être utilisé à des fins d'optimisation. C'est aussi "cachés" de la logique, et peut-être un problème d'entretien. Décider de revoir le schéma ou l'utilisation d'un déclencheur est un appel de jugement à ce point.
De manière générale, je préfère les contraintes et mon code de capture des erreurs de sql server et de présenter quelque chose de plus convivial pour l'utilisateur.
@onedaywhen
Vous pouvez avoir une requête comme une contrainte dans SQL Server, vous avez juste à être en mesure de l'adapter en fonction scalaire:http://www.eggheadcafe.com/software/aspnet/30056435/check-contraints-and-tsql.aspx
CHECKdes contraintes (voir ici).@Mark Brackett: "les Contraintes sont utilisées pour restreindre le domaine... des Déclencheurs sont un moyen de faire respecter la logique d'entreprise": Il n'est pas simple en SQL Server en raison de ses contraintes de fonctionnement est limitée par exemple ne pas encore complète de SQL-92. Prenons l'exemple classique de la séquence primaire de la clé' dans les domaines temporel table de base de données: idéalement, je voudrais utiliser une contrainte de VÉRIFICATION 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, donc je dois utiliser un déclencheur. Il manque également à partir de SQL Server SQL-92 capacité de reporter la vérification de contraintes, mais plutôt qu'ils sont (en effet) vérification après chaque instruction SQL, donc encore une fois un déclencheur peut être nécessaire de travailler autour de SQL Server limites.
Si possible utiliser des contraintes. Ils ont tendance à être slighlty plus rapide. Les déclencheurs doivent être utilisés pour la logique complexe qu'une contrainte ne peut pas gérer. Déclencher l'écriture est délicate et si vous trouvez que vous devez écrire un déclencheur, assurez-vous d'utiliser basés sur les déclarations becasue triigers fonctionnent par rapport à l'ensemble de l'insert, update ou delete (Oui, il y aura des moments où plus d'un enregistrement est affecté, plan de sur la!), pas un seul enregistrement à la fois. Ne pas utiliser un curseur dans un déclencheur si elle peut être évitée.
Aussi loin que de mettre de la logique dans l'application au lieu d'un déclencheur ou une contrainte. NE FAIS PAS ÇA!!! Oui, les applications devraient avoir des contrôles avant d'envoyer les données, mais l'intégrité des données et la logique métier doit être à la base de données de niveau ou de vos données se foiré lorsque plusieurs applications crochet en elle, lorsqu'elle inserts sont fait outsiide l'application, etc. L'intégrité des données est la clé de bases de données et doivent être appliquées au niveau base de données.
@Meff: il y a des problèmes potentiels avec l'approche de l'utilisation d'une fonction tout simplement parce que SQL Server VÉRIFIER les contraintes ont été conçues avec une seule ligne comme l'unité de travail, et a des défauts lorsque l'on travaille sur un jeu de résultats. Pour plus de détails sur cette question, voir: [http://blogs.conchango.com/davidportas/archive/2007/02/19/Trouble-with-CHECK-Constraints.aspx%5D%5B1%5D.
[1]: David Portas Blog: de la Difficulté avec les contraintes de VÉRIFICATION.
Même que Skliwz.
Juste pour vous dire un canonique utilisation de déclencher est de la vérification de la table. Si de nombreuses procédures de mise à jour/insérer/supprimer une table que vous voulez de vérification ( qui a modifié quoi et quand ), le déclencheur est la façon la plus simple de le faire. une façon est de simplement ajouter un drapeau dans votre tableau ( actif/inactif avec une certaine unicité de contrainte ) et insérer quelque chose dans la table d'audit.
Une autre façon, si vous voulez que la table de ne pas tenir l'historique des données est de copier l'ancienne ligne dans votre tableau d'audit...
Beaucoup de gens ont de nombreuses façons de le faire. Mais une chose est sûre, vous aurez à effectuer un insert pour chaque mise à jour/insérer/supprimer dans ce tableau
D'éviter l'écriture de l'insérer dans des dizaines de lieux différents, vous pouvez ici utiliser un déclencheur.
Je suis d'accord avec tout le monde ici à propos de contraintes. Utiliser autant que possible.
Il y a une tendance à abuser des déclencheurs, notamment avec les nouveaux développeurs. J'ai vu des situations où un déclencheur est activé un autre trigger qui déclenche un autre déclencheur qui répète le premier déclencheur, la création d'une cascade de déclencheur pour que les liens de votre serveur. C'est un non-utilisateur optimale 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 bons pour le suivi des modifications dans les données (comme la Marque de Brackett mentionné). Vous devez répondre à la question "Où est-il le plus de sens pour mettre mes affaires de la logique"? La plupart du temps, je pense qu'il appartient dans le code, mais vous devez garder un esprit ouvert.