Supposons que je reçois des procédures stockées qui effectue des opérations d'insertion / de mise à jour / de suppression sur la table.
Selon certains critères, je veux effectuer certaines opérations.
Devrais-je créer une gâchette ou faire l'opération dans la procédure stockée elle-même.
Utilise les déclencheurs diminue les performances?
Ces deux tables est-elle S'ils sont créés de manière dynamique, il a un problème de performance.
S'ils sont des tables persistantes, alors où sont-ils?
Également si ils exixtent alors puis-je accéder à
4 Réponses :
performance sur quoi? La gâchette effectuera une mise à jour sur la DB après l'événement afin que l'utilisateur de votre système ne sache même pas que cela se passe. Cela arrive à l'arrière-plan.
Votre question est formulée de manière assez difficile à comprendre.
Je pense que la question se réfère à la présence des tables insérées et supprimées. Y a-t-il une performance frappée par les structures disponibles. Mon gut dit non, mais je ne suis pas sûr.
Oui, une table avec un déclencheur ne fonctionnera pas aussi bien que sans cela. La logique dicte que faire quelque chose est plus chère que de ne rien faire.
Je pense que votre question serait plus significative si vous demandiez que ce soit plus performant qu'une autre approche que vous n'avez pas spécifiée.
En fin de compte, je choisirais l'outil le plus approprié pour le travail et ne vous inquiétez que des performances s'il y a un problème, pas avant d'avoir même mis en œuvre une solution.
Les tables insérées et supprimées sont disponibles dans la gâchette, les appelant donc des procédures stockées est un non-go.
Tu me as raison, je veux savoir "si elle est plus performante que toute autre approche" Je veux savoir que si des tables insérées et supprimées ne peuvent être accédées que dans des déclencheurs, alors sont-elles créées lorsque les déclencheurs sont tirés ou sont-ils des tables permanentes? et s'ils sont des tables permanentes, alors pourquoi ne pouvons-nous pas y accéder dans des procédures stockées
Insérés et supprimés sont des tables temporaires qui vivent en mémoire pendant la durée de la durée de votre déclenchement. Une fois que votre déclencheur a fini d'exécuter, ils sont partis jusqu'à ce que quelque chose d'autre provoque le déclenchement de la gâchette.
Parfois, penser à la performance avant d'entrer dans une solution est une bonne chose, il n'y a rien de pire que je ne reste plus loin dans un projet que pour réaliser que vous devez recommencer - la performance est quelque chose à considérer dans le choix de la bonne solution avant Vous avez mis en œuvre la mauvaise solution
Il diminue les performances de la requête par définition: la requête fait ensuite quelque chose qu'il n'allait pas faire.
L'autre moyen de regarder c'est ceci: Si vous alliez faire manuellement tout ce que la gâchette fait de toute façon, ils augmentent la performance en sauvegardant un aller-retour.
Prenez-en une étape En outre: cet avantage disparaît si vous utilisez une procédure stockée et que vous utilisez de toute façon un serveur aller-retour.
Cela dépend de la façon dont vous le regardez.
sera-t-il moins performant que de faire la même chose dans un procès stocké. Probablement pas, mais avec toutes les questions de performance que le seul moyen de savoir vraiment est de tester les deux approches avec un ensemble de données réaliste (si vous avez une table d'enregistrement de 2 000 000 ne pas tester avec une table avec 100 enregistrements!)
Cela dit, le choix entre une gâchette et une autre méthode dépend entièrement de la nécessité de l'action en question de se produire, quelle que soit la mise à jour des données, supprimées ou insérées. S'il s'agit d'une règle d'entreprise qui doit toujours arriver, peu importe quoi, un déclencheur est le meilleur endroit pour cela ou vous aurez éventuellement des problèmes d'intégrité des données. Les données dans des bases de données sont fréquemment modifiées des sources autres que l'interface graphique.
Lorsque vous écrivez un déclencheur, bien que vous devriez connaître plusieurs choses. Tout d'abord, la gâchette incendie une fois pour chaque lot, de sorte que vous ayez inséré un enregistrement ou 100 000 enregistrements que la gâchette ne tire qu'une seule fois. Vous ne pouvez jamais assumer que seul un enregistrement sera affecté. Vous ne pouvez pas non plus supposer que ce ne sera toujours qu'un petit jeu d'enregistrements. C'est pourquoi il est essentiel d'écrire tous les déclencheurs comme si vous allez insérer, mettre à jour ou supprimer un million de lignes. Cela signifie que la logique reposante et pas de curseurs ou tandis que des boucles si possible. Ne prenez pas un processus stocké écrit pour gérer un enregistrement et l'appelez dans un curseur dans une gâchette.
N'envoyez également pas d'emails à partir d'un curseur, vous ne souhaitez pas arrêter tous les inserts, mises à jour ou supprimer si le serveur de messagerie est en panne.
Les performances se dégradent que les tables insérées et supprimées sont créées de manière dynamique et les enregistrements sont insérés dans ces tables en déclencheurs. Si nous faisons la même chose dans la procédure stockée, ces tables ne sont pas surprenant, augmentant ainsi la performance.