Quais são os esquemas do SQL Server?

Não sou iniciante no uso de bancos de dados SQL e, em particular, no SQL Server. No entanto, eu tenho sido basicamente um cara do SQL 2000 e sempre fui confundido por esquemas em 2005+. Sim, eu sei a definição básica de um esquema, mas para que eles são realmente usados ​​em uma implantação típica do SQL Server?

Eu sempre usei apenas o esquema padrão. Por que eu iria querer criar esquemas especializados? Por que eu atribuiria qualquer um dos esquemas internos?

EDIT: Para esclarecer, acho que estou procurando os benefícios de esquemas. Se você for usá-lo apenas como um esquema de segurança, parece que as funções do database já estão preenchidas, o que … er .. um … papel. E usá-lo como um especificador de namespace parece ter sido algo que você poderia ter feito com a propriedade (dbo versus user, etc ..).

Eu acho que o que eu estou chegando é, o que os esquemas fazem que você não poderia fazer com os proprietários e os papéis? Quais são os seus benefícios específicos?

    Os esquemas agrupam logicamente tabelas, procedimentos, visualizações em conjunto. Todos os objects relacionados ao employee esquema do employee , etc.

    Você também pode conceder permissions para apenas um esquema, para que os usuários possam ver apenas o esquema ao qual eles têm access e nada mais.

    Apenas como Namespace de códigos C #.

    Eles também podem fornecer um tipo de proteção contra colisão de nomenclatura para dados de plug-in. Por exemplo, o novo recurso Change Data Capture no SQL Server 2008 coloca as tabelas que ele usa em um esquema cdc separado. Dessa forma, eles não precisam se preocupar com um conflito de nomenclatura entre uma tabela do CDC e uma tabela real usada no database e, para essa finalidade, podem sombrear deliberadamente os nomes das tabelas reais.

    Eu sei que é um tópico antigo, mas eu apenas examinei os esquemas e achei que o seguinte poderia ser outro bom candidato para o uso do esquema:

    Em um Datawarehouse, com dados vindos de diferentes fonts, você pode usar um esquema diferente para cada origem e, por exemplo, controlar o access com base nos esquemas. Também evita as possíveis colisões de nomes entre as várias fonts, como outro pôster respondeu acima.

    Se você mantiver seu esquema discreto, poderá dimensionar um aplicativo implantando um determinado esquema em um novo servidor de database. (Isso pressupõe que você tenha um aplicativo ou sistema que seja grande o suficiente para ter uma funcionalidade distinta).

    Um exemplo, considere um sistema que realiza logging. Todas as tabelas de log e SPs estão no esquema [logging]. A criação de log é um bom exemplo, pois é raro (se alguma vez) que outras funcionalidades no sistema se sobreponham (ou seja, junte-se a) a objects no esquema de criação de log.

    Uma dica para usar essa técnica – possui uma cadeia de conexão diferente para cada esquema em seu aplicativo / sistema. Em seguida, implemente os elementos do esquema em um novo servidor e altere sua cadeia de conexão quando precisar escalar.

    Eu tenho a tendência de concordar com Brent neste … veja esta discussão aqui. http://www.brentozar.com/archive/2010/05/why-use-schemas/

    Em resumo … os esquemas não são muito úteis, exceto em casos de uso muito específicos. Torna as coisas confusas. Não os use se puder ajudar. E tente obedecer à regra K (eep) I (t) S (imple) S (tupid).

    Eu não vejo o benefício em aliasing usuários vinculados a esquemas. Aqui está porque ….

    A maioria das pessoas conecta suas contas de usuário a bancos de dados por meio de funções inicialmente. Assim que você atribui um usuário ao sysadmin ou à function de database db_owner, de qualquer forma, essa conta é com alias para a conta de usuário “dbo” ou permissions em um database. Quando isso ocorrer, não importa como você se atribui a um esquema além do seu esquema padrão (que tem o mesmo nome da sua conta de usuário), esses direitos dbo são atribuídos àqueles objects que você cria sob seu usuário e esquema. É meio sem sentido ….. e apenas um namespace e confunde a verdadeira propriedade sobre esses objects. Seu design pobre, se você me perguntar …. quem projetou.

    O que eles deveriam ter feito é criar “Grupos” e eliminar esquemas e funções e apenas permitir que você agrupe grupos de grupos em qualquer combinação que desejar e, em seguida, em cada camada, informe ao sistema se as permissions são herdadas, negadas ou sobregravadas com privilégios personalizados. uns. Isso teria sido muito mais intuitivo e permitiria que os DBAs controlassem melhor quem são os verdadeiros proprietários nesses objects. No momento, está implícito na maioria dos casos que o usuário padrão do SQL Server do dbo tem esses direitos … não o usuário.

    Em uma loja da ORACLE em que trabalhei por muitos anos, os esquemas foram usados ​​para encapsular procedimentos (e pacotes) que se aplicavam a diferentes aplicativos de front-end. Um esquema de ‘API’ diferente para cada aplicativo geralmente fazia sentido, pois os casos de uso, os usuários e os requisitos do sistema eram bem diferentes. Por exemplo, um esquema de ‘API’ era para um aplicativo de desenvolvimento / configuração apenas para ser usado pelos desenvolvedores. Outro esquema de ‘API’ era para acessar os dados do cliente por meio de visualizações e procedimentos (pesquisas). Outro código encapsulado do esquema ‘API’ que foi usado para sincronizar desenvolvimento / configuração e dados do cliente com um aplicativo que tinha seu próprio database. Alguns desses esquemas de ‘API’, embaixo dos capítulos, ainda compartilhariam procedimentos e funções comuns entre si (via outros esquemas ‘COMMON’) onde fazia sentido.

    Eu direi que não ter um esquema provavelmente não é o fim do mundo, embora possa ser muito útil. Realmente, é a falta de pacotes no SQL Server que realmente cria problemas em minha mente … mas esse é um tópico diferente.

    Eu acho que esquemas são como um monte de novos resources (seja para o SQL Server 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 na implementação.

    Parece-me que os esquemas são aproximadamente equivalentes aos namespaces opcionais. Se você estiver em uma situação em que os nomes de objects estão colidindo e a granularidade das permissions não está boa o suficiente, aqui está uma ferramenta. (Eu estaria inclinado a dizer que poderia haver questões de design que deveriam ser tratadas em um nível mais fundamental primeiro.)

    O problema pode ser que, se estiver lá, alguns desenvolvedores começarão a usá-lo casualmente para obter benefícios a curto prazo; e uma vez que está lá, pode se tornar kudzu.

    No SQL Server 2000, os objects criados eram vinculados a esse usuário específico, como se um usuário, digamos, Sam criasse um object, digamos, Funcionários, essa tabela aparecesse como: Sam.Employees. E se Sam estiver saindo da companhia ou se mudar para outra área de negócios? Assim que você excluir o usuário Sam, o que aconteceria com a tabela Sam.Employees? Provavelmente, você teria que alterar a propriedade primeiro de Sam.Employees para dbo.Employess. O esquema fornece uma solução para superar esse problema. Sam pode criar todo o seu object dentro de um esquema, como Emp_Schema. Agora, se ele criar um object Employees within Emp_Schema, o object será chamado de Emp_Schema.Employees. Mesmo se a conta do usuário Sam precisar ser excluída, o esquema não será afetado.

    desenvolvimento – cada um de nossos desenvolvedores obtém seu próprio esquema como uma sandbox para jogar.