richardtallent's questions

Eu tenho uma lista de palavras/frases em uma tabela phrases. Eu tenho outra tabela com um catálogo de texto completo indexando a descriptioncoluna.

Quero preencher uma tabela resultscom um registro para cada frase, e a quantidade de vezes que essa frase foi encontrada na descrição:

INSERT INTO results(phrase, foundcount)
SELECT  phrase, 
    (SELECT COUNT(*) FROM table WHERE CONTAINS(table.description, phrase))
FROM    phrases;

Não importa o quanto eu tente, isso resulta no erro:

Incorrect syntax near `phrase`. Expecting STRING, TEX_LEX, or VARIABLE

Eu realmente prefiro não usar um cursor apenas para poder atribuir cada phraseum a uma variável. Essa é realmente a única opção?

Considere uma junção A LEFT JOIN B ON A.id = B.a_id:

• B.a_idé anulável -- a maioria, mas nem todos os Bregistros apontam para um Aregistro.
• Apode, no máximo , ter apenas um registro correspondente B(lógica de negócios).
• Nem todos os Aregistros têm uma correspondência em B.

Existe uma maneira de dizer ao MSSQL que nunca haverá mais de uma correspondência A: B, permitindo assim que ele crie um atalho para a junção assim que uma correspondência for encontrada para um determinado Aregistro?

Eu pensaria que tal otimização poderia acontecer se B.a_idtivesse um índice único, mas isso não é possível, pois é anulável.

Complicando o problema: A e B estão em bancos de dados diferentes (mesma instância do MSSQL).

Se for importante, estou usando o SQL Server 2008 R2.

Eu tenho uma coluna do tipo "comentário" que raramente é usada - cerca de 6% não nula em uma população de 3 milhões de registros. O comprimento médio (quando usado) é de 6 caracteres e o máximo até agora é de cerca de 3 KB. Um máximo de 4000 caracteres é razoável para este campo. Eu tenho duas opções:

comments varchar(max) NULL -- this is the current column definition
comments varchar(4000) SPARSE NULL

Meu entendimento atual é que, em ambos os casos, um NULLvalor não exigiria armazenamento - apenas o NULLconjunto de bits da coluna e um comprimento 0nos metadados da linha.

Mas para os casos não nulos , um tem clara vantagem sobre o outro?

O ponteiro extra de 4 bytes para colunas esparsas com valores sugere que eles são sempre armazenados fora da linha ou em campos textmuito grandes . varchar(max)É esse o caso?

Nesse caso, eu me inclinaria a usar varchar(max), já que ele só armazena valores fora da linha se o comprimento total da linha exceder 8 KB, e a maioria dos meus valores é curta e é improvável que coloque uma linha acima do limite.

Não vi essa situação específica abordada no BOL, então espero que alguém aqui saiba o suficiente sobre as entranhas do MSSQL para fornecer algumas dicas.

(Se for importante, atualmente estou usando 2008R2, mas espero atualizar em breve para 2014.)

Tenho uma tabela que armazena os resultados das consultas que são executadas pelo menos uma vez ao dia. Há uma bitcoluna que representa se a linha é da execução mais recente de uma consulta específica com um conjunto específico de argumentos. (Sim, é uma dependência funcional, mas uma desnormalização necessária para o desempenho, já que a maioria das consultas nesta tabela está interessada apenas no resultado mais recente.)

Como essa bitcoluna é quase sempre um valor falso, estou procurando a melhor maneira de ajustar as consultas retornando apenas os valores verdadeiros. O particionamento não é uma opção (Edição Standard). Parece que tornar a coluna SPARSE seria uma solução interessante, mas acredito que isso exigiria que eu alterasse a coluna para anulável e usasse NULL em vez de 0 para valores falsos. Parece um pouco kludgy.

Existe uma opção semelhante ao SPARSE que otimizaria o espaço/desempenho para uma coluna de bit não nula com a maioria (bem mais de 99%) de valores falsos?

O artigo de Pinal Dave indica que os valores zero e nulo são otimizados, mas isso não parece certo para mim, pois são valores diferentes - a menos que o MSSQL esteja usando o mesmo mecanismo para colunas não nulas para indicar o valor padrão. Isso seria ótimo se fosse verdade, mas o BOL não menciona isso.

Eu tenho um banco de dados com três "níveis" de objetos: A, Be C. A tabela Atem cerca de 100.000 linhas, Btem 500.000 e Ctem 2 milhões.

Em um ataque de estupidez, projetei o banco de dados para usar tabelas de junção ABe BC, embora sejam 1:me poderiam ter sido representados como um ParentAatributo em Be um ParentBatributo em C. Fiz isso porque pensei na época que esses poderiam ser m:m.

Agora, também tenho uma tabela Dque tem relacionamento am:m com C. Para simplificar o gerenciamento de dados para os usuários, faz sentido permitir que eles se relacionem Dou A, Bem vez de diretamente, cada um deles C.

Então, eu tenho tabelas DAde junção , DBe DC, e uma visão de junção DC2que inclui DC, bem como as DCrelações herdadas das junções de DA-AB-BCe DB-BC. Eu uso um UNION ALL para isso e há alguma lógica de negócios para impedir que os usuários atribuam o mesmo Dregistro em dois níveis.

O problema é que o desempenho de DC2kinda suga. Todas as outras tabelas têm índices de cobertura apropriados para essas junções e os índices de cobertura são agrupados. DC2 não inclui tabelas A, B, Cou D, apenas as tabelas de união.

Há também as tabelas E, F, G e H que são semelhantes a D em como se relacionam com A, B e C.

Quais são algumas estratégias que posso usar para melhorar o desempenho desses relacionamentos herdados?

Já pensou:

• Criar DC2uma exibição indexada não é uma opção, pois UNION não é permitido em uma exibição indexada no MSSQL.
• Eu poderia fazer do DC2 uma tabela e gerenciá-lo com gatilhos, mas isso seria uma dor de cabeça e ainda tenho que lidar com EC2, FC2 etc. não consigo onde
• Mudar AB e BC em atributos de B e C pode, na verdade, desacelerar as coisas, já que as tabelas de junção são mais leves e as tabelas principais não são unidas a DC2 com frequência.