Caius Jard's questions

Recentemente, fiz uma pergunta sobre a melhor estratégia de indexação para uma tabela que deve registrar eventos, em ordem, em relação a um GUID. O GUID é um incômodo, mas é inevitável porque é um FK para outro lugar.

Em termos das consultas que quero fazer, elas são essencialmente da formaSELECT TOP N SomeColumn FROM t WHERE GuidColumn = 'someguid' ORDER BY AutoIncInt DESC

Eu fiz algumas experiências e uma boa abordagem de compensação parece ser:

• Crie a AutoIncIntcoluna na tabela como a chave de clustering exclusiva
• Crie um índice não clusterizado não exclusivo em GuidColumneINCLUDE SomeColumn

No começo eu tinha o índice nonclustering em SomeGuid ASC, AutoIncInt DESC, pensando que ajudaria a ORDER BY AutoIncInt DESCparte da consulta mas o plano permaneceu o mesmo quando eu o removi - nenhuma operação de classificação foi necessária e a consulta apenas atingiu o índice NC, fez um top e um select; parece que o SQLServer é de alguma forma inteligente o suficiente para saber, mesmo quando AutoIncInt não é citado no índice de não clustering, há uma maneira de obter facilmente os dados em ordem / calcular facilmente quais últimas N linhas são necessárias para o TOP

Como esse mecanismo funciona na prática? O índice sem cluster tem uma ordem implícita graças à referência ao índice de cluster, de modo que o SQLS possa deduzir rápida e facilmente de quais nós de índice N eu quero a SomeColumn?

Eu uso algo como o seguinte para preparar um bloco de json:

SET @json = (SELECT 
  @varchar1 as MyVarchar1,
  @varchar2 as MyVarchar2, 
  GetUtcDate() as MyTime FOR JSON PATH);

O Visual Studio reclama que é uma "subconsulta não escalar no lugar de escalar" - existe uma maneira de escrevê-la para que não gere um aviso?

Tenho uma situação em que tenho dois bancos de dados:

• ABCDados
• ABCUsers

Um dos procedimentos armazenados em ABCData precisa realizar uma inserção em uma tabela em ABCUsers. Isso poderia ser apenas codificado:

INSERT ABCUsers.dbo.Table1 VALUES('a');

Mas o próximo problema que encontramos é que queremos fazer backup e reimplantar esses pares de banco de dados para outros bancos de dados com nomes semelhantes para fins de teste e desenvolvimento:

• Dados XYZ
• XYZUsuários

O que significa que o banco de dados XYZData conterá um sproc que não funciona - porque a inserção tem um código fixo ABCUsers.dbo.Table1e não queremos alterá-lo

Poderíamos descobrir o nome do banco de dados atual no sproc, ajustá-lo e executar o sql dinamicamente:

DECLARE @DataDbName sysname = (DB_NAME());
DECLARE @UserDBName NVARCHAR(20) = (SELECT REPLACE(@DataDbName, 'Data', 'Users'));
EXEC CONCAT('INSERT ', @UserDbName, '.dbo.Table1 VALUES(''a'');')

Mas acho que a perspectiva de fazer isso realmente me faz sentir fisicamente doente;) (até porque este é um exemplo massivamente simplificado de dezenas de sprocs, cada um fazendo dezenas de chamadas para outros dbs)

Existe uma maneira de alias de um nome de banco de dados durante sua criação, para que o sproc sempre possa dizer algo como:

INSERT UserDbAlias.dbo.Table1 VALUES('a');

E quando o ABCUsersbanco de dados é criado, o UserDbAlias -> ABCUsersmas quando o XYZUsersdb é criadoUserDbAlias -> XYZUsers

Alternativamente, este é um controle de origem git/tfs - existe uma maneira de escrever a versão de controle de origem do sproc para que ela seja modificada dinamicamente quando implantada e a origem original possa conter algum tipo de espaço reservado para os nomes de banco de dados, mas eles são substituídos por nomes de banco de dados variáveis ​​codificados reais na implantação (automaticamente)

Notas de rodapé: Eu olhei para Uma maneira de fazer referência a outro banco de dados sem codificar seu nome , o que parece descrever meu problema, mas não tem uma resposta. Essa pergunta mencionou "Eu olhei para sinônimos, mas eles não funcionariam com EF6 .." (paráfrase)

Os sinônimos funcionariam para mim? Usamos o EF6, mas não tenho certeza de qual é o problema real em termos de por que não funcionaria. Nosso nome sproc no banco de dados nunca muda, e não precisamos alias do próprio sproc, é o nome da tabela de inserção que precisamos alias. Se o sproc for sempre chamado Sproc1independentemente de estar em ABCDataou XYZData, e a resolução de sinônimos acontecer dentro do sproc, o EF6 teria algum problema com ele?