Qual é o propósito do 'proprietário' do banco de dados?

Há alguma confusão entre os conceitos de banco de dados de 'dbo' (um usuário) e 'db_owner' (uma função fixa) de um lado e o conceito de instância de 'proprietário do banco de dados' do outro lado. O 'dbo' e o 'db_owner' são frequentemente chamados de 'proprietário do banco de dados'. No que você está perguntando, você está falando sobre o proprietário do banco de dados como o principal do servidor que possui o banco de dados.

A teoria é assim: qualquer coisa que possa receber permissões é um arquivo 'seguro' . Todos os protegíveis têm um proprietário. O proprietário de um securável tem controle absoluto sobre o securável e não pode ser negado nenhum privilégio. Os protegíveis no nível da instância são de propriedade dos principais do servidor (logins). Os protegíveis no nível do banco de dados são de propriedade dos principais do banco de dados (usuários). Os principais vêm em dois sabores: primário (identidade) e secundário (adesão). Os protegíveis no nível do servidor são, por padrão, de propriedade do principal do servidor primário registrado no momento. Os protegíveis no nível do banco de dados são de propriedade por padrão da entidade de banco de dados atual, exceto para objetos vinculados ao esquema que, por padrão, são de propriedade do proprietário do esquema. Todos os protegíveis suportam a cláusula AUTHORIZATION no momento da criação para impor um proprietário diferente.ALTER AUTHORIZATIONpode ser usado posteriormente para alterar o proprietário de qualquer protegível.

Como o banco de dados é protegível no nível do servidor, segue-se que, por padrão, ele será de propriedade do principal principal que emitiu a instrução CREATE DATABASE. Ou seja. o login NT do funcionário que partiu.

Então, sua pergunta é realmente " Por que os protegíveis precisam de um proprietário? ". Porque o dono é a raiz da confiança. É o proprietário que concede, nega e revoga a permissão sobre o objeto. Um sistema de segurança pode ser projetado sem proprietários de protegíveis? Provavelmente sim, mas teria que haver algum mecanismo para substituir o papel que os proprietários desempenham no modelo atual. Por exemplo, considere que os protegíveis do pai não têm proprietário (por exemplo, em vez de possuir um protegível, o criador original apenas recebe CONTROLE sobre ele) seria possível criar um securável e revogar o acesso a ele para todos , incluindo ele mesmo. A exigência de um proprietário contorna esse problema, pois um proprietário não pode se trancar.

O efeito colateral pouco conhecido de CREATE DATABASE de criar um protegível (o banco de dados) de propriedade do login original do NT já queimou muitos antes. As regras são as mesmas para todos os protegíveis, mas alguns fatores agravam os problemas do proprietário do DATABASE:

• os outros protegíveis de nível de servidor (ponto de extremidade, função de servidor, logon) são raramente usados, movidos etc.
• os protegíveis no nível do banco de dados geralmente acabam sendo de propriedade dbo(do banco de dados principal) ou de algum outro banco de dados principal e, portanto, o proprietário está contido no banco de dados
• Ter o padrão de propriedade do banco de dados para o principal primário do NT cria um problema de contenção (o proprietário é um NT SID gerenciado pelo AD e não viaja com os arquivos do banco de dados, a conta do NT pode ser digitada etc etc etc.)
• a coisa mais importante: o proprietário do banco de dados tem efeitos colaterais importantes, especificamente o EXECUTE AS context. Este problema posterior é o que queima a maioria dos usuários. Como o Service Broker faz uso extensivo do EXECUTE AS (a entrega da mensagem tem um contexto EXECUTE AS implícito, bem como a ativação da fila que tem um explícito) geralmente são os usuários do Service Broker que descobrem esse problema primeiro.

BTW, Kudos para investigar e corrigir seu problema original :)

O banco de dados owneré uma espécie de retrocesso para um tempo antes do esquema (adequado) ser introduzido no SQL Server 2005.

Basicamente, um proprietário de banco de dados é o padrão dbo(proprietário do banco de dados) do banco de dados, sendo o próprio banco de dados um objeto de banco de dados .

Dos documentos do SQL Server 2000 ...

O dboé um usuário que tem permissões implícitas para realizar todas as atividades no banco de dados.

Nas versões anteriores do SQL Server, quando um esquema não podia "possuir" um objeto ( ou melhor, deveria ser declarado que todos os objetos, tabelas, exibições dboetc. "usuário" para possuí-lo ... não é preciso dizer por que algo precisa possuir o banco de dados (ou então as permissões em geral seriam bastante difíceis.)

Então, tecnicamente em versões mais antigas do SQL Server (ou bancos de dados atualizados) não era a tabela "Foo" era a tabela "dbo.Foo" ... dbosendo o proprietário.

Com o advento do SQL Server 2005, você poderia ter objetos de banco de dados de propriedade do esquema, como dizer que você tem um esquema chamado "bar" e uma tabela chamada "Foo" bar.Foo...

SELECT * FROM bar.Foo WHERE etc = 'blah`;

A parte complicada vem com o fato de que o usuário que cria o banco de dados é automaticamente definido como o proprietário , o que leva a problemas com a rotatividade de funcionários, etc.

Portanto, é uma prática recomendada alterar isso para a saconta ou talvez (na minha experiência) para uma conta de domínio que possa ser administrada pela equipe de operações/TI de uma organização.

Este artigo mostra a diferença entre a maneira mais antiga de "proprietário" de fazer as coisas e o novo sistema de propriedade baseado em "esquema".

Para entender a diferença entre proprietários e esquema, vamos passar algum tempo revisando a propriedade do objeto. Quando um objeto é criado no SQL Server 2000 ou anterior, o objeto deve ter um proprietário. Na maioria das vezes, o proprietário é “dbo”, também conhecido como proprietário do banco de dados.