Questa domanda è già stata posta più volte su SO, ma è interessante notare che non sembra esserci consenso sulla risposta migliore. Quindi ecco un riepilogo delle principali opzioni suggerite da varie persone (senza un ordine speciale):
- Mettilo nel database principale con un
sp_prefisso in modo che SQL Server lo cerchi prima lì - Mettilo nel database del modello, in modo che venga aggiunto automaticamente a tutti i nuovi DB
- Crea un database solo per le procedure 'globali' (e altri oggetti) e chiamale usando la denominazione in tre parti
- Come 3, ma crea sinonimi in altri database in modo da non aver bisogno della denominazione in tre parti
- Utilizza strumenti commerciali o sviluppati in proprio per gestire la distribuzione su più database
- Come 5, ma distribuisci su un database, quindi
diffi database e applicare lo script diff da distribuire ad altri database
A mio parere, 1 non è un inizio perché Microsoft dice esplicitamente non dovresti creare oggetti nel database principale. 2 suona bene, ma in pratica i database vengono ripristinati o copiati più spesso di quelli creati da zero (YMMV), quindi l'utilizzo del modello non è affidabile.
3 e 4 sono utili per tabelle e viste, ma il contesto di esecuzione può essere un problema per le procedure e le funzioni memorizzate. Ma questo dipende dalla logica delle procedure e potrebbe essere praticabile nel tuo caso.
Ma 1-4 hanno tutti il potenziale problema che se hai un solo oggetto, hai solo una versione di quell'oggetto, ed è spesso utile avere versioni diverse disponibili in DB diversi, per il test o semplicemente per clienti diversi.
5 e 6 sono variazioni sullo stesso tema e personalmente trovo che questo sia l'approccio migliore perché l'implementazione è un problema che devi comunque risolvere, quindi potresti anche farlo e assicurarti di avere le conoscenze, gli strumenti e i processi in atto essere in grado di distribuire il codice in modo pulito e rapido su qualsiasi database in modo controllato e automatizzato.
