vstrien's questions

Para fins de relatório, preciso poder consultar dependências entre exibições e tabelas subjacentes no nível da coluna (via sys.sql_expression_dependencies).

Uma maneira de fazer com que o SQL Server armazene colunas referenciadas é usar exibições com limite de esquema. Como alguns de meus usuários também criarão exibições, gostaria de aplicá-las. Tanto quanto eu vi, não é possível permitir que apenas visualizações com schemabinding sejam criadas dentro de um banco de dados do SQL Server (embora isso pareça um requisito legítimo para mim).

Existem outras maneiras de forçar o SQL Server a controlar quais colunas estão sendo referenciadas por quais exibições? Ou existe uma maneira oculta de impor exibições de schemabound no SQL Server?

Um de nossos clientes usa para algumas colunas o tipo de dados DECIMAL(18,0)em seu banco de dados SQL Server 2008R2. Como as colunas crescem muito lentamente, ele propôs recentemente alterar o tipo de dados DECIMAL(5,0)para recuperar algum armazenamento.

De acordo com a biblioteca MSDN , o espaço de armazenamento do tipo de DECIMAL(5,0)dados é, assim como o DECIMAL(9,0)tipo de dados, de 5 bytes. INTé 1 byte menor, mas pode armazenar tudo no intervalo de -2^31 a 2^31 em vez de -99.999 a 99.999 que DECIMAL(5,0)pode armazenar. Mesmo o maior DECIMALque cabe em 5 bytes ( DECIMAL(9,0)) pode armazenar apenas números inteiros no intervalo -999.999.999 a 999.999.999 (que é menos da metade do intervalo INToferecido em 4 bytes).

Posso pensar em dois "benefícios" de usar DECIMALover INT:

• A capacidade de adicionar escala posteriormente, sem usar mais espaço de armazenamento
• A capacidade de escalar a precisão até 38 dígitos, sem alterar o tipo de dados

mas estes não são benefícios reais na minha opinião:

• Adicionar escala a números inteiros só faz sentido em poucos casos (na maioria dos casos em que a escala faz diferença, ela também pode ser adicionada de antemão)
• O SQL Server vê cada combinação de precisão/escala como um tipo de dados diferente, portanto, o tipo de dados não é deixado sozinho ao aumentar a precisão ou a escala.

Isso me faz pensar: qual é o benefício adicional de um DECIMAL(5,0)tipo de dados para números inteiros?

Tenho dois servidores de banco de dados, conectados via Linked Servers. Ambos são bancos de dados SQL Server 2008R2, e a conexão do servidor vinculado é feita por meio de um link "SQL Server" regular, usando o contexto de segurança do logon atual. Os servidores vinculados estão ambos no mesmo datacenter, portanto, a conexão não deve ser um problema.

Eu uso a seguinte consulta para verificar quais valores da coluna identifierestão disponíveis remotamente, mas não localmente.

SELECT 
    identifier 
FROM LinkedServer.RemoteDb.schema.[TableName]

EXCEPT

SELECT DISTINCT
    identifier 
FROM LocalDb.schema.[TableName] 

Em ambas as tabelas há índices não clusterizados na coluna identifier. Localmente são cerca de 2,6 milhões de linhas, remotamente apenas 54. No entanto, ao analisar o plano de consulta, 70% do tempo de execução é dedicado à "execução de consulta remota". Além disso, ao estudar o plano de consulta completo, o número de linhas locais estimadas é 1em vez de 2695380(que é o número de linhas estimadas ao selecionar apenas a consulta posterior a EXCEPT). Ao executar esta consulta, leva muito tempo.

Isso me faz pensar: Por que isso? A estimativa está "apenas" longe ou as consultas remotas em servidores vinculados são realmente tão caras?