Matthew's questions

Frequentemente encontramos a situação "Se não existir, insira". O blog de Dan Guzman tem uma excelente investigação sobre como tornar esse processo seguro para threads.

Eu tenho uma tabela básica que simplesmente cataloga uma string para um número inteiro de um arquivo SEQUENCE. Em um procedimento armazenado, preciso obter a chave inteira para o valor, se existir, ou INSERTobter o valor resultante. Há uma restrição de exclusividade na dbo.NameLookup.ItemNamecoluna, portanto, a integridade dos dados não está em risco, mas não quero encontrar as exceções.

Não é um IDENTITYentão não consigo SCOPE_IDENTITYe o valor pode ser NULLem certos casos.

Na minha situação, só tenho que lidar com INSERTa segurança na mesa, então estou tentando decidir se é melhor praticar usar MERGEassim:

SET NOCOUNT, XACT_ABORT ON;

DECLARE @vValueId INT 
DECLARE @inserted AS TABLE (Id INT NOT NULL)

MERGE 
    dbo.NameLookup WITH (HOLDLOCK) AS f 
USING 
    (SELECT @vName AS val WHERE @vName IS NOT NULL AND LEN(@vName) > 0) AS new_item
        ON f.ItemName= new_item.val
WHEN MATCHED THEN
    UPDATE SET @vValueId = f.Id
WHEN NOT MATCHED BY TARGET THEN
    INSERT
      (ItemName)
    VALUES
      (@vName)
OUTPUT inserted.Id AS Id INTO @inserted;
SELECT @vValueId = s.Id FROM @inserted AS s

Eu poderia fazer isso sem usar MERGEapenas um condicional INSERTseguido por um SELECT . Acho que esta segunda abordagem é mais clara para o leitor, mas não estou convencido de que seja uma prática "melhor"

SET NOCOUNT, XACT_ABORT ON;

INSERT INTO 
    dbo.NameLookup (ItemName)
SELECT
    @vName
WHERE
    NOT EXISTS (SELECT * FROM dbo.NameLookup AS t WHERE @vName IS NOT NULL AND LEN(@vName) > 0 AND t.ItemName = @vName)

DECLARE @vValueId int;
SELECT @vValueId = i.Id FROM dbo.NameLookup AS i WHERE i.ItemName = @vName

Ou talvez haja outra maneira melhor que não considerei

Pesquisei e fiz referência a outras perguntas. Este: https://stackoverflow.com/questions/5288283/sql-server-insert-if-not-exists-best-practice é o mais apropriado que encontrei, mas não parece muito aplicável ao meu caso de uso. Outras questões para a IF NOT EXISTS() THENabordagem que não acho aceitável.

Eu tenho uma tabela modificada em série de eventos processados. Um horário utc para quando foi processado e um eventId.

É seguro usar SYSUTCDATETIME() como minha chave primária? Posso facilmente usar uma chave substituta, mas achei engraçado.

Se eu adicionar ou descartar colunas de uma tabela do SQL Server, presumo que recebo divisões ou lacunas de página. Já que o tamanho da linha mudou.

Quando uso o RedGate SQL Compare para criar scripts de conversão, sua estratégia é criar uma tabela temporária, copiar todos os dados para essa tabela, descartar a tabela antiga e renomear a tabela temporária.

Presumo que isso limpe as páginas, pois todas as linhas foram inseridas "perfeitamente" sequencialmente.

Recentemente, um DBA me disse que essa abordagem de "copiar e renomear" é ineficiente, cara e desnecessária.

Quais são os méritos dessas duas abordagens?

Estou implantando uma tabela de mapeamento que se conecta ItemsaItemGroups

Embora um Itemsempre esteja em um único ItemGroup, aceite a priori que não é apropriado em meu caso de uso anexar uma coluna à Itemstabela.

Assim será criada uma tabela com duas colunas:

ItemId INT NOT NULL
ItemGroupId INT NOT NULL

É tentador fazer ItemIdo CI e PK para esta tabela.... mas isso é adequado? Acho que faz sentido como uma chave primária, mas como não é sequencial nem perpetuamente crescente, parece incorreto como um CI. Eu nunca executarei consultas de intervalo contraItemId

... Mas uma chave substituta apenas para fins de um IC sequencial também não parece apropriada.

Tenho a mesma probabilidade de executar:

SELECT [ItemGroupId] FROM [Table] WHERE [ItemId] = @id
SELECT [ItemId] FROM [Table] WHERE [ItemGroupId] = @id

Tanto quanto eu posso dizer, tenho poucas opções:

1. ItemIdé o CI e o PK
2. ItemIdnão é o CI, mas é o PK
3. ItemIdnão é o CI nem o PK, mas tem uma UNIQUErestrição
4. ItemId, ItemGroupIdcombinação torna-se o PK e ItemIdtem uma UNIQUErestrição

Eu tenho uma tabela do SQL Server que uso para armazenar eventos.

Eu quero apenas que a tabela contenha as 1000 linhas adicionadas mais recentemente, quando a linha 1001 for inserida, a linha 1 deve ser excluída.

Eu tenho uma coluna DateCreatedUTC e uma coluna de numeração automática.... Eu poderia escrever uma consulta para executar uma exclusão e acioná-la, INSERTmas não sei se esta é a solução mais apropriada.

No SQL Server 2008, tenho visualizações WITH SCHEMABINDINGe preciso alterar uma.

Estou alterando uma coluna sem alterar seu alias para que os consumidores não sejam afetados.

Se eu descartasse todas as minhas outras visualizações que dependem disso, seria capaz de recriá-las novamente, portanto SCHEMABINDINGainda é válido.

Posso desativar temporariamente o bloqueio de esquema nesta exibição para ALTERisso?

Ou devo descartar as exibições dependentes e recriá-las depois de alteradas?

Ouvi informações confusas sobre isso e espero uma opinião canônica ou especializada.

Se eu tiver vários LEFT OUTER JOINs , cada um dependente do último, é melhor aninhá-los?

Para um exemplo artificial, o JOINto MyParentdepende do JOINto MyChild: http://sqlfiddle.com/#!3/31022/5

SELECT
    {columns}
FROM
    MyGrandChild AS gc
LEFT OUTER JOIN
    MyChild AS c
        ON c.[Id] = gc.[ParentId]
LEFT OUTER JOIN
    MyParent AS p
        ON p.[id] = c.[ParentId]

Comparado com http://sqlfiddle.com/#!3/31022/7

SELECT
    {columns}
FROM
    MyGrandChild AS gc
LEFT OUTER JOIN
    (
    MyChild AS c            
    LEFT OUTER JOIN
        MyParent AS p
            ON p.[id] = c.[ParentId]
    )
    ON c.[Id] = gc.[ParentId]

Como mostrado acima, eles produzem planos de consulta diferentes em SS2k8

Atualmente, temos vários bancos de dados, mas gostaríamos de combiná-los e, em vez disso, separar nossos contextos de domínio usando esquemas.

No MS SQL Server 2008 R2, como posso realocar todo o conteúdo de um esquema para outro em massa?

Por exemplo, todas as tabelas, visualizações, procedimentos, índices, etc... que criamos no dboesquema agora viverão no fooesquema.

EDIT: Eu queria esclarecer com base nos ótimos comentários de AaronBertrand. Esta não é uma situação de multilocação. Nossa situação é onde os plug-ins de ferramentas internas foram desenvolvidos isoladamente por desenvolvedores que não mesclaram suas tabelas no banco de dados da ferramenta.

No SQL Server 2008 R2+, infelizmente, temos algumas nvarcharcolunas armazenando dados numéricos.

Em alguns casos, queremos SUMos dados quando eles podem ser somados. O problema é que ISNUMERIC()retorna 1 para um número de entradas com parâmetros inválidos para SUM.... Entendo o que está acontecendo aqui, mas estou procurando uma solução alternativa.

Por exemplo ISNUMERIC('10,1') = 1, mas não posso incluir esse valor em um SUM, então gostaria que esse valor fosse excluído de SUM... e quaisquer pontos de dados, de fato, que não possam ser parâmetros SUMsem serem massageados...

Então, estou me perguntando qual é a maneira preferida de determinar se o conteúdo de uma coluna alfanumérica pode ou não ser somado?

EDIT: Vale a pena notar que esta é uma decolagem desta resposta no SO:

https://stackoverflow.com/a/15833014/369775

mas não estou convencido de que os métodos fornecidos nessa resposta sejam ideais. Eu concordo com HLGEM :

https://stackoverflow.com/a/338292/369775

A melhor solução seria parar de armazenar números inteiros em uma coluna varchar. Claramente, há um problema de dados em que os dados são interpretáveis ​​como numéricos, mas não podem ser convertidos como tal.

No SQL Server 2008 R2, estou explorando o uso de tabelas de particionamento.

Temos um esquema de exclusão reversível que às vezes é um IsDeleted bit NOT NULLe às vezes umDateDeleted date NULL

Quero focar no primeiro caso, o bit.

Estou pensando em particionar esta tabela no bit porque a tabela quase sempre é consultada e unida incluindo esta coluna.

Como eu faria esse processo? É uma má ideia?

Primeiro tentei percorrer o assistente, mas o script gerado para mim parecia estranho (várias quedas de restrições, criação de um novo CI)

Usando o MS SQL Server 2008 R2, temos o código .NET e gostaríamos de usar conexões aninhadas com o mesmo banco de dados dentro do mesmo escopo de transação.

Entendo e aceito que isso exigirá escalação para o DTC.

Minha preocupação é que nossa instância sql hospeda banco de dados para aplicativos distribuídos que, em alguns casos, requerem interação apenas por meio de APIs. Se eu habilitar o MSDTC, acredito que ele se aplicará aos bancos de dados... isso significa que, quando consumimos APIs ou outros consomem nossa API na mesma instância SQL, somos potencialmente transações de controlador entre dois aplicativos teoricamente separáveis. Talvez se as ações sql falharem nos métodos empregados pela API, isso não seja da minha conta, e eles não devem saber ou se importar se estou invocando seu método dentro de uma transação de banco de dados.

Portanto, no meu caso específico, se eu pudesse usar o MSDTC apenas em meu único banco de dados, seria apropriado. Estou bem com uma exceção se eu executar uma ação em bancos de dados que exijam escalonamento.

Estou pensando em usar a datetime2(7)como um índice clusterizado.

Se eu sempre preencher essa coluna usando SYSDATETIME, é possível que a mesma instância emita o mesmo valor duas vezes (supondo que não façamos algo como atrasar o relógio do sistema)?

Como alternativa, qual é uma estratégia coesa para garantir exclusividade em tal coluna, mesmo que isso tenha um custo de precisão de tempo?

Para meu uso, eu realmente só me importo com os segundos, mas farei muitas consultas de intervalo nesta coluna para que o CI pareça apropriado.

Esta pergunta é uma decolagem da excelente colocada aqui:

Cast to date é sargável, mas é uma boa ideia?

No meu caso, não estou preocupado com a WHEREcláusula e sim em ingressar em uma tabela de eventos que possui uma coluna do tipoDATE

Uma tabela tem DATETIME2e a outra tem DATE... para que eu possa efetivamente JOINusar uma CAST( AS DATE)ou posso usar uma consulta de intervalo "tradicional" (> = data E < data + 1).

Minha pergunta é qual é preferível? Os DATETIMEvalores quase nunca corresponderão ao valor do predicado DATE.

Espero ficar na ordem de 2 milhões de linhas com o DATETIMEe menos de 5k com o DATE(se essa consideração fizer diferença)

Devo esperar o mesmo comportamento no JOINque eu poderia usar a WHEREcláusula? Qual devo preferir para manter o desempenho com dimensionamento? A resposta muda com o MSSQL 2012?

Meu caso de uso generalizado é tratar minha tabela de eventos como uma tabela de calendário

SELECT
    events.columns
    ,SOME_AGGREGATIONS(tasks.column)
FROM
    events
LEFT OUTER JOIN
    tasks
        --This appropriately states my intent clearer
        ON CAST(tasks.datetimecolumn AS DATE) = events.datecolumn 
        --But is this more effective/scalable?
        --ON tasks.datetimecolumn >= events.datecolumn 
        --AND tasks.datetimecolumn < DATEADD(day,1,events.datecolumn)
GROUP BY
    events.columns

Eu tenho uma tabela que atualmente tem valores duplicados em uma coluna.

Não posso remover essas duplicatas errôneas, mas gostaria de impedir que valores não exclusivos adicionais sejam adicionados.

Posso criar um UNIQUEque não verifique a conformidade existente?

Já tentei usar NOCHECKmas não obtive sucesso.

Nesse caso, tenho uma tabela que vincula as informações de licenciamento a "CompanyName"

EDIT: Ter várias linhas com o mesmo "CompanyName" é um dado incorreto, mas não podemos remover ou atualizar essas duplicatas neste momento. Uma abordagem é fazer com que os INSERTs usem um procedimento armazenado que falhará para duplicatas... Se fosse possível que o SQL verificasse a exclusividade por conta própria, seria preferível.

Esses dados são consultados pelo nome da empresa. Para as poucas duplicatas existentes, isso significará que várias linhas serão retornadas e exibidas... Embora isso esteja errado, é aceitável em nosso caso de uso. O objetivo é evitar isso no futuro. Parece-me pelos comentários que tenho que fazer essa lógica nos procedimentos armazenados.

O SQL Server armazena DATETIMEinternamente como dois INTvalores, como explica o SQLDenis .

Está correto (por extensão lógica) que DATEos tipos (SQL Server 2008+) são armazenados como um único INT ?

Ao projetar um esquema de dados do servidor SQL e as consultas subsequentes, sprocs, exibições, etc., a noção de um índice clusterizado e a ordem dos dados no disco faz algum sentido a considerar para projetos de banco de dados feitos explicitamente para serem implantados em plataformas SSD?

http://msdn.microsoft.com/en-us/library/aa933131(v=sql.80).aspx
"Um índice agrupado determina a ordem física dos dados em uma tabela."

Em uma plataforma de disco físico, o design para considerá-los faz sentido para mim, pois uma varredura física dos dados para recuperar linhas "sequenciais" pode ter mais desempenho do que uma busca na tabela.
Em uma plataforma SSD, todos os acessos de leitura de dados usam uma busca idêntica. Não há conceito de "ordem física" e as leituras de dados não são "sequenciais" no sentido de que os bits são armazenados no mesmo pedaço de silício.

Portanto, no processo de design de um banco de dados de aplicativo , a consideração do índice clusterizado é relevante para esta plataforma?

Meu pensamento inicial é que não é porque a ideia de "dados ordenados" não se aplica ao armazenamento de SSDs e à otimização de busca/recuperação.

EDIT: Eu sei que o SQL Server criará um, só estou filosofando se faz sentido pensar nisso durante o design/otimização.