De que servem os esquemas do servidor SQL?
não sou principiante em usar bases de dados SQL, e em particular o servidor SQL. No entanto, eu tenho sido principalmente um SQL 2000 cara e eu sempre fui confuso por esquemas em 2005+. Sim, eu sei A definição básica de um esquema, mas para que eles realmente são usados em um típico servidor SQL implantação?
Sempre usei o esquema padrão. Porque haveria de querer criar esquemas especializados? Porque atribuiria algum dos esquemas incorporados?Editar: para clarificar, acho que estou a olhar para os benefícios dos regimes. Se você só vai usá-lo como um esquema de segurança, parece que os papéis da base de dados já preencheram isso.. er.. hum.. funcao. E usá-lo como um especificador de espaço de nomes parece ter sido algo que você poderia ter feito com a propriedade (dbo versus usuário, etc..).
Acho que o que quero dizer é, o que os esquemas fazem que não se podem fazer com donos e papéis? Quais são os benefícios específicos?11 answers
Esquemas como logicamente tabelas de grupos, procedimentos, vistas em conjunto. Todos os objectos relacionados com os empregados do esquema employee, etc.
Você também pode dar permissões a apenas um esquema, de modo que os usuários só podem ver o esquema a que eles têm acesso e nada mais.
Eles também podem fornecer uma espécie de proteção de colisão de nome para dados de plugin. Por exemplo, o novo recurso de captura de dados de mudança no SQL Server 2008 coloca as tabelas que ele usa em um esquema cdc separado. Desta forma, eles não têm que se preocupar com um conflito de nome entre uma tabela CDC e uma tabela real usada na base de dados, e por essa matéria pode deliberadamente sombra os nomes das tabelas reais.
Eu sei que é um tópico antigo, mas acabei de ver os esquemas e acho que o seguinte pode ser outro bom candidato para o uso do esquema:
Numa Datawarehouse, com dados provenientes de diferentes fontes, pode usar um esquema diferente para cada fonte e, por exemplo, controlar o acesso com base nos esquemas. Também evita as possíveis colisões de nomes entre as várias fontes, como outro pôster respondeu acima.
Se mantiver o seu esquema discreto, poderá escalar uma aplicação através da aplicação de um dado esquema a um novo servidor DB. (Isto assume que você tem um aplicativo ou sistema que é grande o suficiente para ter funcionalidade distinta).
Um exemplo, considere um sistema que executa o registo. Todas as tabelas de registro e SPs estão no esquema [logging]. Logging é um bom exemplo porque é raro (se alguma vez) que outras funcionalidades do sistema se sobrepõem (que é juntar a) objetos no esquema de Registo.
Uma dica para usar esta técnica -- tem um texto de ligação diferente para cada esquema na sua aplicação / Sistema. Em seguida, você implanta os elementos do esquema para um novo servidor e altera o seu texto de conexão quando você precisa escalar.
A maioria das pessoas liga as suas contas de Utilizador às bases de dados através de papéis inicialmente, assim que atribuir um Utilizador quer ao sysadmin, quer ao DB_ proprietário da base de dados, de qualquer forma, essa conta ou é aliada à conta de utilizador "dbo", ou tem permissões completas numa base de dados. Uma vez que isso ocorre, não importa como você se atribui a um esquema além do seu esquema padrão (que tem o mesmo nome que o seu usuário conta), esses direitos dbo são atribuídos aos objetos que você cria sob o seu usuário e esquema. É inútil.....e apenas um espaço de nomes e confunde a verdadeira propriedade desses objectos. Na minha opinião, é um mau design....quem o desenhou.
O que eles deveriam ter feito era criar "grupos" , e jogar fora esquemas e papel e apenas permitir que você agrupar grupos de grupos em qualquer combinação que você gosta, então em cada nível diga ao sistema se as permissões são herdadas, negadas, ou reescritas com personalizadas. Isso teria sido muito mais intuitivo e permitiu que a DBA controlasse melhor quem são os verdadeiros donos desses objetos. Neste momento está implícito na maioria dos casos o usuário padrão do servidor SQL do dbo tem esses direitos....não o utilizador.
Acho que os esquemas são como um monte de novas funcionalidades (seja para o servidor SQL ou qualquer outra ferramenta de software). Você precisa avaliar cuidadosamente se o benefício de adicioná-lo ao seu kit de desenvolvimento compensa a perda de simplicidade no design e implementação.
Parece-me que os esquemas são aproximadamente equivalentes a espaços de nomes opcionais. Se você está em uma situação em que os nomes de objetos estão colidindo e a granularidade das permissões não é suficiente, aqui está uma ferramenta. (Eu estaria inclinado a dizer pode haver questões de design que devem ser tratadas a um nível mais fundamental em primeiro lugar.)O problema pode ser que, se ele está lá, alguns desenvolvedores vão começar casualmente a usá-lo para benefício de curto prazo; e uma vez que ele está lá, ele pode se tornar kudzu.
No SQL Server 2000, os objectos criados estavam ligados a esse utilizador em particular, como se um utilizador, digamos, O Sam cria um objecto, digamos, Empregados, que a mesa apareceria como o Sam.Funcionario. O sobre se o Sam está a deixar o compnay ou se muda para outra área de negócios. Assim que apagar o utilizador Sam, o que aconteceria ao Sam.Mesa de empregados? Provavelmente, terias de mudar de roupa. a posse primeiro do Sam.Empregados para dbo.Empregada. O Schema fornece uma solução para supere este problema. Andre pode criar todos os seus objetos dentro de um esquema como Emp_Schema. Agora, se ele cria um objeto Empregados dentro do Emp_Schema então o objeto seria referido como Emp_Schema.Funcionario. Mesmo que a conta de usuário Sam precisa ser excluído, o o esquema não seria afectado.