Deze vraag is al meerdere keren gesteld op SO, maar interessant genoeg lijkt er geen consensus te zijn over het beste antwoord. Dus hier is een samenvatting van de belangrijkste opties die verschillende mensen hebben voorgesteld (in willekeurige volgorde):
- Zet het in de hoofddatabase met een
sp_prefix zodat SQL Server het daar eerst zoekt - Zet het in de modeldatabase, zodat het automatisch wordt toegevoegd aan alle nieuwe DB's
- Maak alleen een database voor 'algemene' procedures (en andere objecten) en roep ze aan met behulp van driedelige naamgeving
- Als 3, maar maak synoniemen in andere databases zodat u de driedelige naamgeving niet nodig hebt
- Gebruik commerciële of zelfontwikkelde tools om implementatie naar meerdere databases te beheren
- Als 5, maar implementeren in één database, dan
diffde databases en pas het diff-script toe om in andere databases te implementeren
Naar mijn mening is 1 een niet-starter omdat Microsoft expliciet zegt u moet geen objecten in de hoofddatabase maken. 2 klinkt goed, maar in de praktijk worden databases vaker hersteld of gekopieerd dan helemaal opnieuw gemaakt (YMMV), dus het gebruik van het model is onbetrouwbaar.
3 en 4 zijn goed voor tabellen en views, maar de uitvoeringscontext kan een probleem zijn voor opgeslagen procedures en functies. Maar dit hangt af van de logica in de procedures en kan in jouw geval werkbaar zijn.
Maar 1-4 hebben allemaal het potentiële probleem dat als je maar één object hebt, je maar één versie van dat object hebt, en het is vaak handig om verschillende versies beschikbaar te hebben in verschillende DB's, om te testen of alleen voor verschillende klanten.
5 en 6 zijn variaties op hetzelfde thema en persoonlijk vind ik dit de beste aanpak omdat implementatie een probleem is dat je toch moet oplossen, dus je kunt het net zo goed doen en ervoor zorgen dat je over de kennis, tools en processen beschikt om op een gecontroleerde, geautomatiseerde manier code schoon en snel in elke database te kunnen implementeren.