In che modo l'utilizzo di schemi separati influisce sulle prestazioni di SQL Server 2008?

Voglio usare schemi separati per oggetti con scopi diversi nel nostro database di SQL Server 2008. In questo momento usiamo una convenzione di denominazione abbastanza insensibile per indicare lo scopo di una tabella o di una procedura memorizzata, e i prefissi indicano che dobbiamo scansionare cinque o sei caratteri x prima ancora di vedere l'inizio del nome univoco. Vorrei usare schemi separati per le tabelle che sono appena utilizzate per guidare l'interfaccia utente (menu, ruoli per persona, ecc.) E per quelle che sono tabelle dimensionali vs. tabelle dei fatti, ecc.

La mia domanda è: ci saranno impatti sulle prestazioni derivanti dall'utilizzo di più schemi (schemae?) Che si opponevano al buon vecchio dbo per tutto?

Potrebbe esserci un impatto sulle prestazioni di Query Optimizer, anche se piccolo, a seconda del tuo stile di codifica. Se si fa riferimento a una tabella senza uno schema, l'ottimizzatore deve provare prima a identificare la tabella controllando le tabelle all'interno dello schema predefinito degli utenti (se presente), quindi utilizzando dbo. E quindi tutto il resto. Se fai esplicitamente riferimento alle tabelle come schema.table, che probabilmente è comunque una buona pratica, anche questo sovraccarico minore sarà evitato.

Nessuna differenza nelle prestazioni. Tuttavia, stai utilizzando gli schemi in questo momento (anche se non lo conosci).

L'uso di riferimenti allo schema oggetti come tavoli, stored procedure, UDF, ecc che sono senza schema qualificato non avere un impatto sulle prestazioni. I riferimenti devono sempre essere qualificati dallo schema. Tali riferimenti non qualificati devono essere risolti e ciò accade in questo modo:

• Innanzitutto, cerca un oggetto con lo stesso nome e tipo nello schema predefinito dell'utente sotto le cui credenziali è stata stabilita la sessione (ad es jsmith.). Se trovato, viene utilizzata quell'istanza.
• Altrimenti, cerca un oggetto con lo stesso nome e tipo nello schema dbo.

Ciò ha diversi effetti:

• Nella maggior parte dei casi, sono necessarie due ricerche per risolvere il riferimento anziché la singola ricerca richiesta se il riferimento è qualificato da schema.
• Il piano di esecuzione ottenuto quando la funzione query / stored procedure / definita dall'utente è associata non può essere memorizzato nella cache e riutilizzato.

L'effetto finale che troverai - dolorosamente - solo quando qualcosa si rompe è che utenti diversi possono ottenere risultati diversi da una determinata query o procedura memorizzata. Qualcosa del genere select * from foo join barpotrebbe funzionare bene per me come proprietario del db; potrebbe essere danneggiato per l'utente jsmithche, inavvertitamente o no, ha creato una tabella denominata foosotto il proprio schema ( jsmith.foo) nello stesso database.

Anche per questo motivo createe le dropistruzioni devono qualificare come schema il nome dell'oggetto che viene creato o eliminato.