A cosa servono gli schemi di SQL Server?

Non sono un principiante nell'uso di database SQL, in particolare SQL Server. Tuttavia, sono stato principalmente un ragazzo di SQL 2000 e sono sempre stato confuso dagli schemi nel 2005+. Sì, conosco la definizione di base di uno schema, ma a cosa servono realmente in una tipica distribuzione di SQL Server?

Ho sempre usato lo schema predefinito. Perché dovrei voler creare schemi specializzati? Perché dovrei assegnare uno degli schemi integrati?

EDIT: Per chiarire, immagino che sto cercando i benefici degli schemi. Se lo utilizzerai solo come schema di sicurezza, sembra che i ruoli del database abbiano già ricoperto quel ruolo ... ehm ... ehm. E usarlo come identificatore di spazio dei nomi sembra essere stato qualcosa che avresti potuto fare con la proprietà (dbo contro utente, ecc.).

Immagino che cosa sto ottenendo è, cosa fanno gli schemi che non potresti fare con i proprietari e i ruoli? Quali sono i loro vantaggi specifici?

Gli schemi raggruppano logicamente tabelle, procedure e viste insieme. Tutti gli oggetti relativi ai dipendenti nello employeeschema, ecc.

Puoi anche assegnare autorizzazioni a un solo schema, in modo che gli utenti possano vedere solo lo schema a cui hanno accesso e nient'altro.

Proprio come lo spazio dei nomi dei codici C #.

Possono anche fornire una sorta di protezione anticollisione dei nomi per i dati dei plugin. Ad esempio, la nuova funzionalità Change Data Capture in SQL Server 2008 inserisce le tabelle che utilizza in uno schema cdc separato. In questo modo, non devono preoccuparsi di un conflitto di denominazione tra una tabella CDC e una tabella reale utilizzata nel database, e del resto possono deliberatamente oscurare i nomi delle tabelle reali.

So che è un vecchio thread, ma ho appena esaminato gli schemi e penso che quanto segue potrebbe essere un altro buon candidato per l'utilizzo dello schema:

In un Datawarehouse, con dati provenienti da fonti diverse, è possibile utilizzare uno schema diverso per ciascuna fonte, quindi ad esempio controllare l'accesso in base agli schemi. Evita anche le possibili collisioni di denominazione tra le varie fonti, come ha risposto un altro poster sopra.

Se si mantiene discreto lo schema, è possibile ridimensionare un'applicazione distribuendo un determinato schema su un nuovo server DB. (Ciò presuppone che tu abbia un'applicazione o un sistema abbastanza grande da avere funzionalità distinte).

Un esempio, considera un sistema che esegue la registrazione. Tutte le tabelle di registrazione e gli SP si trovano nello schema [registrazione]. La registrazione è un buon esempio perché è raro (se mai) che altre funzionalità nel sistema si sovrappongano (ovvero si uniscano a) oggetti nello schema di registrazione.

Un suggerimento per l'utilizzo di questa tecnica: disporre di una stringa di connessione diversa per ogni schema nell'applicazione / sistema. Quindi si distribuiscono gli elementi dello schema su un nuovo server e si modifica la stringa di connessione quando è necessario ridimensionare.

Tendo ad essere d'accordo con Brent su questo ... vedi questa discussione qui. http://www.brentozar.com/archive/2010/05/why-use-schemas/

In breve ... gli schemi non sono tremendamente utili tranne che per casi d'uso molto specifici. Rende le cose disordinate. Non usarli se puoi aiutarlo. E cerca di obbedire alla regola K (eep) I (t) S (imple) S (tupid).

Non vedo il vantaggio di aliasare gli utenti legati agli schemi. Ecco perché ....

La maggior parte delle persone collega i propri account utente ai database tramite ruoli inizialmente, non appena si assegna un utente al sysadmin o al ruolo di database db_owner, in qualsiasi forma, tale account viene aliasato rispetto all'account utente "dbo" o ha pieno autorizzazioni su un database. Una volta che ciò si verifica, indipendentemente da come ti assegni a uno schema oltre lo schema predefinito (che ha lo stesso nome del tuo account utente), quei diritti dbo vengono assegnati a quell'oggetto che crei sotto il tuo utente e schema. È un po 'inutile ..... e solo uno spazio dei nomi e confonde la vera proprietà su quegli oggetti. Il suo design scadente se me lo chiedi ... chiunque lo abbia progettato.

Quello che avrebbero dovuto fare è creare "Gruppi", eliminare schemi e ruoli e consentire semplicemente di raggruppare gruppi di gruppi in qualsiasi combinazione che ti piace, quindi ad ogni livello dire al sistema se le autorizzazioni sono ereditate, negate o sovrascritte con personalizzato quelli. Ciò sarebbe stato molto più intuitivo e avrebbe permesso ai DBA di controllare meglio chi sono i veri proprietari su quegli oggetti. In questo momento è implicito nella maggior parte dei casi l'utente predefinito di SQL Server dbo ha quei diritti .... non l'utente.

In un negozio ORACLE in cui ho lavorato per molti anni, sono stati usati schemi per incapsulare procedure (e pacchetti) applicati a diverse applicazioni front-end. Uno schema 'API' diverso per ogni applicazione aveva spesso senso in quanto i casi d'uso, gli utenti e i requisiti di sistema erano piuttosto diversi. Ad esempio, uno schema "API" prevedeva che un'applicazione di sviluppo / configurazione potesse essere utilizzata solo dagli sviluppatori. Un altro schema 'API' era per l'accesso ai dati del client tramite viste e procedure (ricerche). Un altro codice "API" incapsulato utilizzato per sincronizzare sviluppo / configurazione e dati client con un'applicazione con il proprio database. Alcuni di questi schemi "API", sotto le copertine, condividerebbero comunque procedure e funzioni comuni tra loro (tramite altri "COMUNI"

Dirò che non avere uno schema non è probabilmente la fine del mondo, anche se può essere molto utile. Davvero, è la mancanza di pacchetti in SQL Server che crea davvero problemi nella mia mente ... ma questo è un argomento diverso.

Penso che gli schemi siano come molte nuove funzionalità (che si tratti di SQL Server o di qualsiasi altro strumento software). È necessario valutare attentamente se il vantaggio di aggiungerlo al kit di sviluppo compensa la perdita di semplicità nella progettazione e nell'implementazione.

Mi sembra che gli schemi siano approssimativamente equivalenti agli spazi dei nomi opzionali. Se ti trovi in ​​una situazione in cui i nomi degli oggetti si scontrano e la granularità delle autorizzazioni non è abbastanza buona, ecco uno strumento. (Sarei propenso a dire che potrebbero esserci problemi di progettazione che dovrebbero essere affrontati prima a un livello più fondamentale.)

Il problema può essere che, se è presente, alcuni sviluppatori inizieranno a utilizzarlo casualmente per ottenere vantaggi a breve termine; e una volta che è dentro può diventare kudzu.

In SQL Server 2000, gli oggetti creati erano collegati a quel particolare utente, come se un utente, dicesse Sam, crea un oggetto, ad esempio Dipendenti, che la tabella apparirebbe come: Sam.Employees. Che dire se Sam sta lasciando la compagnia o si trasferisce in un'altra area d'affari. Non appena si elimina l'utente Sam, cosa accadrebbe alla tabella Sam.Employees? Probabilmente, dovresti prima cambiare la proprietà da Sam.Employees a dbo.Employess. Lo schema fornisce una soluzione per superare questo problema. Sam può creare tutto il suo oggetto all'interno di uno schema come Emp_Schema. Ora, se crea un oggetto Employees all'interno di Emp_Schema, l'oggetto verrebbe indicato come Emp_Schema.Employees. Anche se l'account utente Sam deve essere eliminato, lo schema non sarebbe interessato.

sviluppo - ognuno dei nostri sviluppatori ottiene il proprio schema come sandbox in cui giocare.

Ecco un buon esempio di implementazione dell'uso di schemi con SQL Server. Avevamo diverse applicazioni ms-access. Volevamo convertirli in un portale dell'app ASP.NET. Ogni applicazione ms-access è scritta come un'app per quel portale. Ogni applicazione ms-access ha le sue tabelle di database. Alcuni di questi sono correlati, li inseriamo nello schema dbo comune di SQL Server. Il resto ha i suoi schemi. In questo modo, se vogliamo sapere quali tabelle appartengono a un'app sul portale dell'app ASP.NET che può essere facilmente navigata, visualizzata e gestita.