O esquema dbo deve ser evitado?

Pode ser uma boa prática porque quando você tem outros usuários usando o banco de dados, você quer 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, posso acessar qualquer coisa no HResquema, como ITdiretor posso ver nomes de usuários e 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, eu teria mais dificuldade em segmentar meus dados e fornecer funções de acesso.

A ideia, acredito, no SQL Server é oferecer um produto que possa ser acessado e consultado por diferentes departamentos. Na realidade, apenas DBAs/DBDevs realmente acessam o banco de dados e normalmente armazena apenas dados de aplicativos.

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 esquema é grego para plano, ter uma estrutura de esquema definida ajuda você a planejar e identificar dados.

Eu acho que isso realmente se resume à preferência do usuário, pois não há nenhuma razão tecnológica real para fazer isso. Na verdade, para simplificar, eu digo sempre use dbo, a menos que seus requisitos de segurança estipulem o contrário. Claro, você sempre pode fazer isso apenas para fins organizacionais.

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

Onde trabalho, usamos esquemas para dividir o banco de dados em seções lógicas e atribuir 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 qualquer coisa para o banco de dados, um esquema de teste será usado como parte do processo de importação. Se tivermos procedimentos armazenados do sistema aos quais os usuários não precisam acessar, os colocaremos em um esquema sp.

Não era uma prática recomendada anteriormente porque os esquemas eram ocultos antes do SQL 2005, tudo era colocado no esquema dbo. A equipe do SQL Server mostra isso como uma prática recomendada e publicou um artigo sobre isso: Práticas recomendadas do SQL Server – Implementação de esquemas de objetos de banco de dados

Quanto à sua outra pergunta sobre quem deve ser o proprietário: o esquema dbo é de propriedade da conta de usuário dbo.