SQL Server: convenzioni per la denominazione di uno schema

Question

Si consideri un server database il cui lavoro è oggi di ospitare un database. Probabilmente il database verrà spostato in futuro in un'altra istanza di database che ospita più database & schemi.

Facciamo finta che l'app/progetto si chiami Invoicer 2.0. Il database si chiama AcmeInvoice. Il database contiene tutte le informazioni su fattura, cliente e prodotto. Ecco un diagramma degli attori e dei loro ruoli e comportamenti.

Lo schema (s) sarà in gran parte utilizzato per assegnare facilmente i permessi ai ruoli. Il vantaggio ulteriore qui è che gli oggetti non sono sotto dbo e che gli oggetti autorizzazioni & possono essere portati su un'altra macchina in futuro.

Domanda

• Cosa convenzioni si usa quando denominazione lo schema?
• È buona forma dare un nome allo schema uguale al database?

Answer 1

Penso che se il nome dello schema termina con lo stesso schema del database, si aggiunge semplicemente ridondanza al database. Trova oggetti nel database che hanno scopo o scopo comuni e crea uno schema per relegare tale ambito. Ad esempio, se si dispone di un'entità per Fatture e si dispone di alcune tabelle di ricerca di supporto per gli stati di fatturazione e così via, inserirli tutti in uno schema di fatturazione.

Come regola generale, proverei a evitare di utilizzare un nome che rifletta il nome dell'applicazione, il nome del database o altre cose concrete/fisiche perché possono cambiare e trovare un nome che concettualmente rappresenti lo scopo dei tuoi oggetti entrerà nello schema.

tuo commento afferma che "gli schemi in gran parte essere utilizzati per assegnare facilmente i permessi ai ruoli". Il diagramma mostra specifici tipi di utenti che hanno accesso ad alcune/tutte le tabelle o ad alcuni/tutti i proc memorizzati. Penso che cercare di organizzare concettualmente gli oggetti in schemi e organizzarli da un punto di vista della sicurezza in schemi sia qualcosa di conflittuale. Io sono a favore della creazione di ruoli in SQL Server in modo da riflettere i tipi di utenti, e Grant quei ruoli accesso agli oggetti specifici che ogni tipo di utente esigenze, come apposto a concedere il ruolo o l'accesso degli utenti lo schema per costruire il tuo quadro di sicurezza ..

Answer 2

Perché dovresti nominare lo schema come il database? Ciò significa che tutti gli oggetti del database rientrano nello stesso schema. Se questo è il caso, perché avere uno schema?

In genere gli schemi vengono utilizzati per raggruppare oggetti all'interno di un ambito comune di attività o funzione. Ad esempio, dato ciò che hai descritto, potresti avere uno schema di fattura, uno schema di cliente e uno schema di prodotto. Tutti gli oggetti relativi alla fattura entrano nello schema della fattura, tutti gli oggetti relativi al cliente entrano nello schema del cliente e lo stesso per i prodotti.

Spesso utilizziamo anche uno schema comune che include oggetti che potrebbero essere comuni a tutta la nostra applicazione.

Answer 3

Chiamerei il database AcmeInvoice (o un altro nome adatto) e lo schema Invoicer2.

Le mie ragioni sono le seguenti: Acmeinvoice significa che sto raggruppando tutte queste applicazioni oggetti/dati insieme. Può quindi essere spostato come un'unità su altre macchine (un backup/ripristino o unattach/attach).

Lo schema sarebbe Invoicer2. Le applicazioni cambiano, forse in futuro avrai Invoicer21 (creerai uno schema), o forse un modulo o un sistema di reporting (schema dei report). Trovo che l'uso di schemi mi consenta di separare i dati/le procedure in un database in diversi gruppi che semplificano l'ammissione delle autorizzazioni.