Jason Whitish's questions

O exemplo com o qual estou trabalhando é um modelo de dados de fatura, onde pode haver cerca de 30 colunas quando terminarmos de projetar. Cada linha de dados seria exclusiva para uma única fatura.

Algumas das colunas são usadas por várias partes do aplicativo (número da fatura, obviamente, totais de cobrança, etc.), mas existem algumas colunas que são usadas apenas por um único processo.

Por exemplo, temos três colunas que refletem os números de controle ( varchar(18)) usados ​​por clientes externos que devemos rastrear, mas apenas o processo de rastreamento analisa essas colunas. Os números de controle são geralmente de um para um na fatura, portanto, haveria apenas um número de controle por fatura. Existem também algumas faturas que simplesmente não terão um número de controle porque são faturas mais antigas sendo importadas de um sistema que não registrava números de controle (elas representarão cerca de 25% dos dados iniciais). Mesmo essas faturas mais antigas podem eventualmente obter um número de controle (embora provavelmente sejam antigas o suficiente para não acontecer).

Faz mais sentido pegar essas colunas e fazer uma tabela separada para elas, de uma perspectiva de modelagem de dados ou de desempenho, ou devemos apenas deixá-las na tabela Faturas? As respostas para este exemplo específico são apreciadas, mas também estou curioso sobre uma resposta mais geral, pois certamente nos depararemos com esse tipo de cenário novamente.

Com base em como li este artigo da Wikipedia , pretendo dizer particionamento vertical, pelo menos em um sentido lógico (as duas tabelas diferentes estariam no mesmo armazenamento físico neste caso).

Isso faz parte de um banco de dados OLTP.

Provavelmente 75% das linhas terão um número de controle eventualmente.

Estou tendo um problema em que, de forma intermitente, um procedimento armazenado está causando o disparo de um gatilho de banco de dados. O gatilho é para CREATE_FUNCTION, CREATE_PROCEDURE, CREATE_TABLE, CREATE_VIEW, CREATE_TRIGGER , mas o procedimento em si não faz nenhuma dessas coisas. É um procedimento de gravação direto que usa um parâmetro XML e insere os valores em um conjunto de tabelas. A única coisa que é incomum (para nós) é que está usando WITH XMLNAMESPACES, mas parece estranho que esse seja o problema.

Isenção de responsabilidade: Estou resolvendo este problema de uma vez removido. Estou tendo que confiar nos desenvolvedores originais que eles também não estão tentando criar um objeto como parte de seu código acima do banco de dados (eles dizem que é o caso). Também estou verificando todas as tabelas que estão sendo gravadas agora para garantir que elas não tenham gatilhos estranhos que tentem fazer algo que não deveriam. Até agora, não consegui duplicar o efeito em um ambiente de teste, mesmo ao representar um usuário com acesso mínimo. Isso está em um servidor SQL Server 2014.

Esse problema veio à tona porque o objetivo do gatilho do banco de dados é apenas permitir que o login "build" crie objetos no banco de dados.

Então, para manter minha pergunta estreita, é possível WITH XMLNAMESPACESser o problema aqui?

ATUALIZAÇÃO: Como acompanhamento, consegui obter as informações necessárias. Parece que o erro estava sendo causado porque o código de chamada, depois de chamar o procedimento armazenado em questão, também chamou:

exec sp_describe_first_result_set N' EXEC usp_Problem_procedure @P1 ',N'@P1 xml'

E parece que isso é o que realmente está causando o erro. Também parece que o gatilho não foi o único problema. Mesmo corrigir ou desabilitar o gatilho causou um erro posterior:

Msg 11528, Level 16, State 1, Procedure sp_describe_first_result_set, Line 1
The metadata could not be determined because statement 'REVERT

    --Check if SSB is enabled in this database' in procedure 'sp_send_dbmail' does not support metadata discovery.

Aparentemente, um dos procs aninhados tem o potencial de usar sp_send_dbmail (desencorajamos isso, fwiw, pois destruiu o servidor Exchange mais de uma vez).

Então é isso. Assim que mostrei aos desenvolvedores o que estava acontecendo, eles reconheceram que só precisavam chamar um método um pouco diferente, e isso evitou o problema.