O esquema dbo deve ser evitado?


29

Quando se trata do esquema dbo:

  • É uma prática recomendada evitar o uso do esquema dbo ao criar objetos de banco de dados?
  • Por que o esquema dbo deve ser evitado ou deveria?
  • Qual usuário do banco de dados deve possuir o esquema dbo?

Alguns consultores disseram que é uma boa prática evitar o esquema dbo e sempre criar esquemas definidos pelo usuário e atribuir objetos a esses esquemas.
jrara

Encontrei essa declaração também de Alexander Kuznetsov nos comentários deste post do blog :
jrara

Respostas:


22

Pode ser uma boa prática, porque quando você tiver outros usuários usando o banco de dados, poderá limitar o acesso deles com esquemas. Por exemplo, em um banco de dados, você tem as seguintes tabelas.

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

Como diretor de RH, sou capaz de acessar qualquer coisa no HResquema; como ITdiretor, posso ver os nomes de usuários e os níveis de acesso dos funcionários. O Engineeringdepartamento pode ver quais locais de trabalho estão ativos etc. Se dbo fosse o esquema definido para todas as tabelas, seria mais difícil segmentar meus dados e fornecer funções de acesso.

A idéia, acredito, no SQL Server, é oferecer um produto que possa ser acessado e consultado por diferentes departamentos. Na realidade, apenas os DBAs / DBDevs realmente acessam o banco de dados e, normalmente, apenas armazenam dados do aplicativo.

Também ajuda na legibilidade e capacidade de gerenciamento. À primeira vista, posso identificar facilmente qual tabela contém quais dados e como os dados são separados.

Pessoalmente, prefiro definir esquemas como uma prática geral. Lembre-se de que o esquema é grego para o plano, ter uma estrutura de esquema definida ajuda a planejar e identificar dados.


6

Eu acho que isso realmente se resume à preferência do usuário, pois não há motivo tecnológico real para fazer isso. De fato, por uma questão de simplicidade, digo sempre use dbo, a menos que seus requisitos de segurança estipulem o contrário. Obviamente, você sempre pode fazer isso apenas para fins organizacionais.


1
100% por trás dessa abordagem. Geralmente deixo as tabelas "principais" no esquema dbo por simplicidade e começo a adicionar quando necessário. Normalmente, o primeiro esquema separado que adiciono é "Stage" ou "Staging", para agrupar minhas tabelas temporárias separadamente. Outro exemplo seria adicionar dados de uma fonte externa, diz o Twitter. Em vez de prefixar todas as tabelas (por exemplo, TwitterAccount, TwitterStatus etc.), criarei um esquema "Twitter".
robopim

5

Se alguma coisa, o dbo deve ser evitado, porque é o padrão para o SQL Server, também não é descritivo. Como todos os outros nomes padrão, uma vez que é pré-conhecido, facilita a vida de um hacker (embora se eles estejam no ponto em que estão apenas tentando descobrir o nome do seu esquema, você provavelmente já deve ter trabalhado).

Onde trabalho, usamos esquemas para dividir o banco de dados em seções lógicas e atribuímos permissões aos esquemas.

Por exemplo, podemos ter um sistema de inventário com um banco de dados. As tabelas principais podem estar no esquema inv. Se importarmos alguma coisa para o banco de dados, um esquema de preparação será usado como parte do processo de importação. Se tivermos procedimentos armazenados no sistema aos quais os usuários não precisam acessar, os colocaremos em um esquema sp.


1
+1 para "evite porque é o padrão". Força os usuários a pelo menos pensar um pouco quando criam um objeto.
BradC

Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.