Lo schema dbo dovrebbe essere evitato?

Quando si tratta dello schema dbo:

• È consigliabile evitare di utilizzare lo schema dbo durante la creazione di oggetti di database?
• Perché lo schema dbo dovrebbe essere evitato o dovrebbe?
• Quale utente del database dovrebbe possedere lo schema dbo?

Potrebbe essere una buona pratica perché quando hai altri utenti che utilizzano il database vuoi essere in grado di limitare il loro accesso con schemi. Ad esempio in un database sono disponibili le seguenti tabelle.

HR.Payhist
HR.Payscale
HR.Jobdesc
IT.username
IT.useraccesslevel
ENG.jobsite
ENG.trainings

Come direttore delle risorse umane sono in grado di accedere a qualsiasi cosa nello HRschema, in quanto ITdirettore posso vedere i nomi utente e i livelli di accesso dei dipendenti. Il Engineeringdipartimento può vedere quali siti di lavoro sono attivi, ecc. Se dbo fosse lo schema impostato per tutte le tabelle, avrei più difficoltà a segmentare i miei dati e fornire ruoli di accesso.

L'idea, credo, in SQL Server è quella di offrire un prodotto a cui sia possibile accedere e interrogare da reparti diversi. In realtà solo DBA / DBDev accedono realmente al database e in genere memorizza solo i dati dell'applicazione.

Aiuta anche con leggibilità e gestibilità. A prima vista posso facilmente identificare quale tabella contiene quali dati e come i dati sono separati.

Personalmente preferisco definire gli schemi come pratica generale. Ricorda che lo schema è greco per piano, avere una struttura di schema strutturata ti aiuta a pianificare e identificare i dati.

Penso che questo dipenda davvero dalle preferenze dell'utente in quanto non esiste un vero motivo tecnologico per farlo. In effetti, per semplicità, dico sempre di usare dbo a meno che i vostri requisiti di sicurezza non stabiliscano diversamente. Certo, puoi sempre farlo anche solo per scopi organizzativi.

Semmai, dbo dovrebbe essere evitato perché è il valore predefinito per SQL Server, inoltre non è affatto descrittivo. Come tutti gli altri nomi predefiniti, dato che è noto, rende la vita di un hacker molto più semplice (anche se se sono nel punto in cui stanno solo cercando di capire il nome del tuo schema, probabilmente sei già bloccato).

Nel luogo in cui lavoro, utilizziamo gli schemi per suddividere il database in sezioni logiche e assegnare autorizzazioni agli schemi.

Ad esempio, potremmo avere un sistema di inventario con un database. Le tabelle principali potrebbero essere nello schema inv. Se importiamo qualcosa nel database, verrà utilizzato uno schema di gestione temporanea come parte del processo di importazione. Se disponiamo di procedure memorizzate nel sistema a cui gli utenti non hanno bisogno di accedere, le inseriamo in uno schema sp.

In precedenza non era una buona pratica perché gli schemi erano nascosti prima di SQL 2005, tutto veniva inserito nello schema dbo. Il team di SQL Server lo mostra come best practice e ha pubblicato un articolo al riguardo: Best practice di SQL Server - Implementazione di schemi di oggetti di database

Per quanto riguarda l'altra tua domanda su chi dovrebbe possederlo: lo schema dbo è di proprietà dell'account utente dbo.