Uso eccessivo / uso corretto degli schemi?

Dopo aver posto questa domanda su StackOverflow , mi chiedevo dove ciò che ho fatto fosse la migliore / migliore pratica.

Fondamentalmente, ogni oggetto che creo sta andando in uno schema con il nome dello schema che riflette un uso. Ad esempio, ho gli schemi Audite Admin(tra gli altri).

Questo a sua volta non lascia oggetti dbo. Va bene? C'è qualcos'altro che devo fare?

Gli schemi non sono solo un ottimo strumento di sicurezza (che è una ragione sufficiente per usarli), ma sono anche perfetti per la separazione logica. E sembra che questo sia ciò che stai praticando.

Anche se l'attuale requisito non richiede una sicurezza speciale, dire lungo la strada che tutti gli oggetti di database correlati al controllo dovrebbero essere protetti da un ruolo del database. Se questi oggetti fossero sparsi in tutto lo dboschema, allora dovresti esplicitamente denyautorizzazioni sui singoli oggetti. Ma con lo Auditschema, fai un singolo denye sei pronto.

Personalmente pratico l'uso di schemi. Come tutte le cose nei database, tuttavia, esiste un mezzo felice. Non creerei uno schema per ogni aspetto granulare del livello dati. Esistono troppi schemi e separazione. Ma suppongo che tu non sia vicino a quello.

Un modello tipico è rappresentato da schemi basati su autorizzazioni, quindi si dovrebbe avere WebGUI, Desktopecc. Per il codice in modo che tutti gli oggetti abbiano le stesse autorizzazioni dallo schema .

Se hai gruppi di utenti chiari, puoi autorizzarli, ma a un certo punto finirai con autorizzazioni sovrapposte e disordinate. Tendo a rinviare i controlli utente / gruppo ad alcuni controlli all'interno del codice e non agli oggetti delle autorizzazioni: supponiamo di avere utenti Admin e HR Excel: questi eseguono tutti il Desktopcodice.

I dati sono generalmente condivisi, quindi avrei uno Dataschema, forse uno Historyo uno Archiveschema.

Alcuni codici non sono pubblici (come un UDF o un proc interno) quindi utilizzerei uno Helperschema per il codice che non dovrebbe essere eseguito dal codice client.

Infine, gli schemi come Stagingo Systemo Maintenancesono utili a volte.

Sebbene non ci siano oggetti utente nello dboschema, l'utente dbopossiede tutti gli schemi.

Nessun oggetto nello dboschema va perfettamente bene. Da quello che posso vedere non è nemmeno un uso eccessivo di schemi, anche se quanti schemi sono "troppi" è una domanda abbastanza soggettiva (è paragonabile a "Quante classi dovrebbe avere il mio progetto OO?").

L'unica altra cosa che vorrei menzionare sarebbe quella di concedere autorizzazioni sullo schema anziché singoli oggetti (la tua domanda SO non specifica nulla sulle autorizzazioni).

Vorrei utilizzare gli schemi per separare il database in base ai moduli e ai modelli di utilizzo. Trovo che semplifichi la comprensione delle tabelle del database, quindi la manutenzione diventa più semplice. Ho avuto i seguenti tipi di schema nel mio ultimo progetto server SQL. LT - Tabelle di ricerca

COMMON
LT_COMMON
MODULENAME1
LT_MODULENAME1
..

Per moduli di grandi dimensioni, li abbiamo anche separati in più schemi. Ad esempio il modulo personale è composto da più di 5 moduli.

PERSONEL_COMMON
PERSONEL_FINANCE
PERSONEL_MODULE2
..
LT_PERSONEL_COMMON
LT_PERSONEL_FINANCE
LT_PERSONEL_MODULE2

Abbiamo anche incluso schemi come per altre attività TEMP, MAINTANENCE. In Management Studio, è possibile filtrare utilizzando il nome dello schema. Uno sviluppatore responsabile di MODULE1, filtra in base al nome e funziona quasi sempre con solo queste tabelle. Questo rende molto facile per gli sviluppatori, dbas, sia per i nuovi arrivati ​​capire le tabelle del database.

Le migliori pratiche possono essere diverse per SQL Server rispetto a Oracle, tuttavia la mia esperienza è che meno schemi, meglio è.
Mi piace avere uno schema per il dba / programmatore che ha privilegi speciali e un po 'di codice per eseguire la manutenzione. Tutti i dati aziendali dovrebbero andare in uno schema in modo da sapere dove si trovano. Le convenzioni di denominazione sono sufficienti per distinguere tra l'uso della tabella o il codice memorizzato.
Vedo un caso in cui hai più unità aziendali a causa di dati diversi con una piccola sovrapposizione ciascuno con il proprio schema. Altrimenti mantienilo semplice.