Na semana passada, discutimos o conceito de ‘Piores Práticas’ no SQL Server, que são práticas que são o oposto das ‘Melhores Práticas’. Neste artigo, vamos aprofundar uma prática ruim específica – a propriedade de objeto.

Para aqueles que são novos no SQL ou não estão familiarizados com o conceito, todo objeto no SQL Server (como tabelas, visualizações e procedimentos armazenados) tem um proprietário. O proprietário é determinado pelo usuário que tem permissões para criar o objeto e realmente o cria. Você pode identificar facilmente o proprietário de um objeto usando ferramentas como o Enterprise Manager.

Agora, você pode estar se perguntando por que a propriedade de objeto é considerada uma prática ruim. A principal razão é que ela pode levar a confusão e erros. Quando você escreve uma instrução select que se refere a uma tabela sem especificar o proprietário, o SQL Server assume que você é o proprietário do objeto. Por exemplo, se você escrever:

SELECT * FROM Categories

O SQL Server tentará primeiro executar a instrução como:

SELECT * FROM SeuNomeDeUsuário.Categories

Se o objeto não existir sob sua propriedade, ele tentará então:

SELECT * FROM dbo.Categories

Essa etapa extra de determinar o objeto correto leva tempo e pode afetar o desempenho. Embora seja considerado uma boa prática sempre qualificar objetos com um proprietário, na realidade, os desenvolvedores muitas vezes omitem o proprietário para economizar tempo e tornar o código mais conciso.

No entanto, o problema surge quando os objetos são de propriedade de diferentes usuários. Digamos que você tenha duas tabelas Categories, uma de propriedade de dbo e outra de propriedade de um usuário chamado wp. Sua equipe de desenvolvimento escreve um aplicativo que usa a tabela Categories de propriedade de dbo, mas eles não qualificam completamente o objeto. Durante os testes, tudo parece bem. No entanto, quando você instala o aplicativo para um usuário chamado WP, eles relatam ver apenas cinco categorias, enquanto outro usuário chamado BP vê oito. O problema é que WP e BP estão usando sem saber tabelas diferentes com o mesmo nome, causando confusão e resultados incorretos.

Este exemplo pode parecer forçado, mas destaca os problemas potenciais que podem surgir da propriedade de objeto. É essencial manter as permissões e a propriedade o mais simples e clara possível para evitar tais problemas.

Outra razão para evitar a propriedade de objeto é o conceito de cadeias de propriedade. As cadeias de propriedade determinam se um usuário deve ter acesso a um objeto ou seus dados. Quando todos os objetos são de propriedade do mesmo usuário, o processo é simples. No entanto, quando as cadeias de propriedade são quebradas, o SQL Server precisa realizar verificações adicionais, o que pode afetar o desempenho.

Embora alguns desenvolvedores ou DBAs usem a propriedade de objeto sem intenção, é crucial evitar que isso aconteça. Uma maneira de fazer isso é não conceder permissões aos usuários para criar objetos, a menos que sejam membros da função db_owner. Alternativamente, você pode permitir que os usuários prossigam e, em seguida, usar o procedimento armazenado sp_changeobjectowner para alterar o proprietário para dbo antes de implantar o código. No entanto, a abordagem anterior geralmente é considerada a melhor solução.

Você concorda comigo nessa questão? Ou você tem uma perspectiva diferente? Vamos discutir mais nos comentários abaixo!