To pytanie było już wielokrotnie zadawane na SO, ale co ciekawe, wydaje się, że nie ma zgody co do najlepszej odpowiedzi. Oto podsumowanie głównych opcji sugerowanych przez różne osoby (bez specjalnej kolejności):
- Umieść go w głównej bazie danych z
sp_prefiks, aby SQL Server najpierw go tam szukał - Umieść go w bazie danych modelu, aby był automatycznie dodawany do wszystkich nowych baz danych
- Utwórz bazę danych tylko dla procedur „globalnych” (i innych obiektów) i wywołuj je przy użyciu trzyczęściowego nazewnictwa
- Jak 3, ale utwórz synonimy w innych bazach danych, aby nie potrzebować trzyczęściowego nazewnictwa
- Użyj komercyjnych lub samodzielnie opracowanych narzędzi do zarządzania wdrażaniem w wielu bazach danych
- Jako 5, ale wdrażaj w jednej bazie danych, a następnie
diffbazy danych i zastosuj skrypt diff do wdrożenia w innych bazach danych
Moim zdaniem 1 nie jest startowy, ponieważ Microsoft wyraźnie mówi nie należy tworzyć obiektów w bazie danych master. 2 brzmi nieźle, ale w praktyce bazy danych są przywracane lub kopiowane częściej niż tworzone od zera (YMMV), więc korzystanie z modelu jest zawodne.
3 i 4 są dobre dla tabel i widoków, ale kontekst wykonania może stanowić problem dla procedur i funkcji składowanych. Ale to zależy od logiki procedur i może być wykonalne w twoim przypadku.
Ale wszystkie 1-4 mają potencjalny problem polegający na tym, że jeśli masz tylko jeden obiekt, masz tylko jedną wersję tego obiektu i często przydatne jest posiadanie różnych wersji dostępnych w różnych bazach danych, do testowania lub tylko dla różnych klientów.
5 i 6 to wariacje na ten sam temat i osobiście uważam, że jest to najlepsze podejście, ponieważ wdrożenie jest problemem, który i tak musisz rozwiązać, więc równie dobrze możesz to zrobić i upewnić się, że masz wiedzę, narzędzia i procesy aby móc wdrażać kod w sposób czysty i szybki w dowolnej bazie danych w kontrolowany, zautomatyzowany sposób.
