Lo schema dbo dovrebbe essere evitato?


29

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?

Alcuni consulenti hanno affermato che è buona norma evitare schemi dbo e creare sempre schemi definiti dall'utente e assegnare oggetti in questi schemi.
jrara,

Ho trovato questa dichiarazione anche da Alexander Kuznetsov nei commenti di questo post sul blog :
jrara

Risposte:


22

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.


6

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.


1
100% dietro questo approccio. Lascio spesso le tabelle "core" nello schema dbo per semplicità e comincio ad aggiungere quando necessario. In genere il primo schema separato che aggiungo è "Stage" o "Staging", per raggruppare le mie tabelle di staging separatamente. Un altro esempio potrebbe essere l'aggiunta di dati da una fonte esterna, ad esempio Twitter. Invece di aggiungere un prefisso a tutte le tabelle (ad esempio TwitterAccount, TwitterStatus ecc.), Creerò uno schema "Twitter".
robopim,

5

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.


1
+1 per "evitalo perché è il valore predefinito". Obbliga gli utenti a pensarci almeno un po 'quando creano un oggetto.
BradC,

Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.