Best-Practices per l'utilizzo di schemi in SQL Server (2008)

Question

Nel database AdventureWorks è possibile vedere che schemi diversi vengono utilizzati per raggruppare le tabelle. Perché questo è fatto (sicurezza, ...?) E ci sono le migliori pratiche che riesco a trovare?

thx, Lieven Cardoen

Answer 1

Come manager di Business Intelligence, che si basano su schema per raggruppamento logico e la sicurezza di gestione. Qui ci sono alcuni casi di come usiamo lo schema:

LOGICO ORGANIZZAZIONE

1. Abbiamo un database generale che viene caricato da pacchetti SSIS solo per i dati di sosta prima di carichiamo il nostro negozio di dati operativi (ODS). In questo database, ad eccezione dello schema, tutti gli oggetti sono di tipo indentico (nomi di tabelle, nomi di colonne, tipi di dati, valori null, ecc.) Alla loro origine originale. Utilizziamo lo schema per indicare il sistema di origine originale della tabella. In alcuni rari casi, due database diversi hanno tabelle con lo stesso nome e lo schema ci consente di continuare a utilizzare il nome originale nel database di staging.

2. In ogni database sui nostri server BI ogni membro del team ha uno schema test_username. Quando creiamo oggetti di prova in un database, è facile tenere traccia di chi ha creato l'oggetto. Inoltre rende molto più semplice eliminare gli oggetti di prova in seguito, poiché tutti sanno chi ha fatto cosa. Sinceramente, sapere che ce l'abbiamo fatta di solito basta sapere che può essere cancellato in modo sicuro, soprattutto quando non possiamo ricordare quando o perché l'abbiamo fatto!

3. Nel nostro database di controller di dati, ci affidiamo allo schema per separare diversi tipi di processi tra report, etl e risorse generiche.

4. Nel nostro data warehouse dello schema a stella, tutti gli oggetti sono suddivisi in schemi di dimensioni e fatti.

5. Quando trasferiamo i dati ad altri server dipartimentali, facciamo in modo che tutti gli oggetti BI sui loro server utilizzino lo schema bi. Ciò rende VERAMENTE facile conoscere i carichi e mantiene la tabella anche se non è sul nostro server. Se il server di destinazione non è una casella di SQL Server 2008/2005, quindi si prefissa la tabella con bi_.

Quando si arriva al dunque, usiamo schema per qualsiasi momento organizzazione logica avremmo aggiunto un prefisso o suffisso a un oggetto per aiutare ad organizzare in assenza di schema. Detto questo, ci sono alcuni casi in cui non usiamo lo schema sui nostri server BI. Nel nostro WorkingDB, tutto è dbo. Il nostro WorkingDB è usato come TempDB per creare tabelle temporanee, ma queste tabelle sono tabelle temporanee che sappiamo che creeremo ogni volta che viene eseguito un processo ETL. La proprietà speciale di WorkingDB è che non eseguiamo mai il backup del database e tutti i processi ETL che utilizzano il database devono essere in grado di ricreare i loro oggetti da zero in assenza della tabella. In questo caso, abbiamo ritenuto che l'uso dello schema non aggiungesse QUALSIASI valore organizzativo poiché non utilizziamo effettivamente gli oggetti al di fuori del loro processo ETL temporaneo.

SICUREZZA

1. Dato che siamo un gruppo di BI, in genere non ci costruire e sostenere le nostre applicazioni. Utilizziamo quasi esclusivamente le applicazioni di altre persone e trasferiamo i dati dai loro database di back-end al nostro server. Tuttavia, abbiamo un database chiamato bi_applications che è il back-end per una varietà di piccole applicazioni CRUD.Queste applicazioni sono in genere moduli di immissione dati che forniamo al business in modo che possano acquisire dati che altrimenti dovremmo mantenere in BI. È un modo per ottenere i dati che dovrebbero essere contenuti nelle applicazioni di produzione nella BI mentre attendiamo che i nostri miglioramenti alle applicazioni a bassa priorità raccolgano la polvere nelle future liste di sviluppo. Ogni applicazione ha uno schema separato e l'account dell'applicazione utilizzato per aggiornare le tabelle sottostanti ha accesso SOLO agli oggetti dello schema associato. Questo rende davvero facile capire, proteggere e mantenere le applicazioni separate.

2. In alcuni casi, ho consentito agli utenti esperti di accedere direttamente al database alle nostre tabelle o alle stored procedure. Ci affidiamo all'utilizzo dello schema combinato con i ruoli per proteggere gli oggetti. Concediamo le autorizzazioni allo schema e gli utenti vengono aggiunti ai ruoli. Questo ci permette di capire facilmente quali oggetti vengono usati da chi senza dover scavare attraverso i ruoli per capirlo.

Insomma, usiamo lo schema per motivi di sicurezza, quando probabilmente ci hanno considerato che separa gli oggetti fuori nelle proprie basi di dati e quando ci aspettiamo che un'applicazione o un utente al di fuori della BI per accedere ai nostri database.

Anche se queste non sono le migliori pratiche commerciali per gli sviluppatori di applicazioni, spero che i miei casi di utilizzo in due possano aiutarti a pensare ad alcuni dei modi per utilizzare lo schema nella tua parte finale dell'azienda.