Un de mes développeurs a écrit une fonction SQL qui fonctionne comme la fonction VB.Net (LastIndexOf) et souhaite la publier. Ma question est quelle serait la raison de mettre cela dans une base de données centrale par rapport à le mettre dans chaque base de données utilisateur?
Le développeur essayait de le mettre dans le schéma sys sur sa base de données principale afin qu'il n'ait pas à qualifier les appels vers celui-ci à partir des bases de données utilisateur ... soupir
Mais je ne savais pas quelle serait l'excuse valable pour la centraliser (évidemment pas la base de données principale) par rapport à chaque base de données d'utilisateurs?
sql-server
performance
functions
ddl
David George
la source
la source
Réponses:
La façon dont je préfère le faire: mettre la fonction dans une base de données utilitaire et créer un synonyme dans chaque base de données régulière. De cette façon, vous obtenez le meilleur des deux mondes:
par exemple
Ceci est particulièrement puissant pour les fonctions CLR, car il y a des frais administratifs supplémentaires pour les modifier / déployer.
Et cela est préférable à l'utilisation de master (et au marquage en tant qu'objet système, ce qui n'est pas garanti d'être transférable). J'aimerais cependant savoir comment votre développeur prévoit de créer sa fonction dans le
sys
schéma.Je comprends que la maintenance de plusieurs copies d'une fonction dans 500 bases de données n'est pas vraiment plus difficile que la maintenance d'une seule copie, mais avoir plusieurs copies n'est vraiment un avantage que si vous avez des exceptions (par exemple, le client A veut que sa fonction gère les NULL différemment, ou quelque chose). Dans ce cas, je laisserais le synonyme dans toutes les autres bases de données et n'introduirais une version spéciale de la fonction que dans cette base de données.
(Cela suppose que la fonction ne repose sur aucun accès aux données dans la base de données d'un client, bien sûr - ce qui peut certainement compliquer les choses.)
la source
Je vais devoir être en désaccord avec Aaron (et la réponse acceptée).
L'approche d'Aaron est la façon dont j'aime traiter les "trucs DBA", par exemple les scripts de maintenance. Je ne voudrais jamais faire cela avec une fonction de bibliothèque qui serait appelée par une base de données utilisateur.
Pourquoi? Vous vous dirigerez vers l'équivalent de base de données de DLL Hell .
Installez .net 4.5 sur un serveur exécutant une application .net 2.0 et que se passe-t-il? Rien, votre application continue d'utiliser le framework 2.0. Mettez à jour votre fonction LastIndexOf sur un serveur hébergeant 3 bases de données d'applications (dans le cadre d'une mise à niveau vers l'une d'entre elles) et que se passe-t-il? Tous les trois utilisent maintenant la dernière version.
L'alternative est l'approche adoptée par SQL # . Celui-ci est installé sur un schéma dans chaque base de données utilisateur, vous pouvez donc mettre à niveau la base de données pour Application-X en toute sécurité sans risquer la stabilité d'Application-Y.
Si vous travaillez dans un environnement de gestion des changements étroitement contrôlé, vous n'aurez pas le choix, vous ne pouvez pas mettre à niveau un composant partagé sans tester tous les consommateurs du composant. Si vous travaillez quelque part un peu plus "rapide et lâche", vous êtes libre de tenter votre chance en cassant quelque chose involontairement avec un correctif / mise à niveau.
la source
LastIndexOf
à changer, encore moins d'une manière qui ne casse que certaines applications / bases de données. Je dirais que c'est un plus gros problème pour CLR ou des fonctions vraiment centrales / complexes qui desservent plusieurs applications. (3) Ma préférence actuelle serait de ne pas utiliser du tout une fonction pour des tâches simples.Utility
données pour des trucs de bibliothèque communément appelés, mais cela augmente un peu le risque et nécessite des tests approfondis.La réponse à cette question dépend de si nous parlons d'objets T-SQL ou d'objets SQLCLR. Il existe différents (et plus) facteurs à prendre en compte lors du traitement des objets SQLCLR.
En termes d'objets T-SQL, les deux réponses apportent ici des points valides. Comme décrit dans la réponse de @ Aaron , la base de données centrale peut être très pratique, et les synonymes peuvent être utilisés pour faciliter le pointage de certaines bases de données vers la ressource partagée et d'autres d'utiliser une ressource locale. Mais le point soulevé dans la réponse de Mark concernant le risque accru en raison de la dépendance plus forte ne peut être ignoré.
Cependant, si vous traitez avec des objets SQLCLR, vous devez d'abord considérer tous les points que j'ai soulevés dans la réponse suivante:
Comment mieux utiliser la fonction CLR du point de vue des performances (répéter à l'intérieur de chaque base de données ou avoir une fonction générale)?
la source