Quando devo usar o tipo de dados XML no SQL Server?

Quando devo usar o tipo de dados XML no Microsoft SQL Server?

Fiz uma coisa semelhante em que serializo dados de objetos em XML para armazenamento. Isso elimina o ônus de ter tabelas, colunas e relacionamentos em vigor para armazenar dados para objetos complexos. O processo pode ser ajudado usando um esquema ao qual o XML resultante está em conformidade e as tabelas do banco de dados podem ser usadas para meta-informações sobre os objetos em questão. No meu caso, expandir o esquema do banco de dados para acomodar o layout do objeto seria uma grande tarefa!

Pessoalmente, nunca usei o tipo de campo XML no SQL Server antes e fiz muita programação de banco de dados desde que eles adicionaram esse recurso. Sempre me pareceu haver uma sobrecarga programática e de desempenho no uso nativo de conteúdo XML em um banco de dados. Sinceramente, pensei que era um truque, porque todo mundo estava no trem XML em um ponto no início dos anos 2000. "Oh XML é quente, então vamos adicioná-lo ao SQL Server para não parecermos ultrapassados".

O melhor caso de negócios que posso ver pode estar na gravação de mensagens de dados baseadas em XML que você recebeu, onde você pode espiar em sua estrutura e dados, mas deseja manter a integridade da mensagem original por motivos comerciais ou legais. A sobrecarga pode ser muito grande para converter o XML em uma estrutura de tabela, mas o uso dos recursos XML no SQL Server pode reduzir o custo de examinar os dados o suficiente para justificá-lo.

Provavelmente, existem dezenas de outras razões pelas quais você deseja usá-lo, mas, francamente, acho que você deve considerar outros caminhos para a felicidade antes de ficar louco com o XML no SQL Server, a menos que você tenha motivos comerciais muito específicos para isso. Use um varchar (max) ou um campo de texto se fizer mais sentido.

Apenas minha opinião, claro :)

Eu encontrei apenas alguns cenários em que perseguiria ativamente o uso do tipo de dados XML no SQL Server. Isso está no topo da minha cabeça, na ordem do menos ao mais interessante:

• Armazenando / arquivando respostas XML geradas por outros aplicativos
  • Por exemplo, usamos o Application Integration Framework (AIF) para a comunicação entre um aplicativo Silverlight personalizado e o Dynamics AX. Armazenamos mensagens de entrada e saída no banco de dados para ajudar na solução de problemas de comunicação entre esses aplicativos
  • Como o tipo de campo é XML em vez de um tipo genérico de sequência (ou seja, VARCHAR), podemos usar o XQuery para consultar especificamente mensagens que correspondam a alguns critérios específicos. Isso seria muito mais difícil com uma string simples como correspondência
• Armazenando em cache / mantendo uma mensagem de resposta composta
  • Atualize o campo XML com um código de acionador ou aplicativo, que imitaria uma coluna computada
  • Em vez de regenerar constantemente uma resposta XML para um aplicativo de chamada baseado, você incorreria em sobrecarga somente quando a linha for aumentada, em vez de em todas as chamadas
  • Isso funciona melhor quando os SELECTs são muito mais frequentes do que UPDATEs / INSERTs, o que tende a ser verdadeiro para a maioria dos aplicativos
• Armazenando vários valores em um único campo
  • Uma das práticas que vi é o uso do tipo de dados XML para armazenar uma coleção de valores em um único campo
  • Um benefício é que você não precisa criar um conjunto extra de tabelas para um armazenamento simples de chave / valor
  • Uma desvantagem disso é que os dados não são totalmente normalizados, tornando as consultas menos óbvias
  • No entanto, como mencionado acima, você pode usar o XQuery nesse campo XML para selecionar linhas que correspondam aos critérios de identificação, assim nuetralizando parcialmente o impacto de não ser totalmente normalizado.

Tudo isso dito, 99% do tempo, não tenho absolutamente nenhuma necessidade de um campo XML ao projetar um esquema.

Nas poucas vezes em que vi o tipo de dados XML no SQL server, ele foi basicamente usado como um campo que foi consultado como qualquer outro no banco de dados, o que pode ter implicações muito ruins no desempenho se você tiver uma grande quantidade de dados . Há um motivo pelo qual é chamado de servidor SQL e não servidor XML. :-) As consultas que vão contra o XML simplesmente não são tão rápidas quanto uma consulta de seleção regular.

Eu pude ver isso sendo usado para armazenar XML que não é muito consultado, digamos, armazenar o documento XML completo em um tipo de dados XML, mas ter os campos pesquisáveis ​​(chaves) armazenados separadamente com o documento XML. Dessa forma, você pode consultar suas informações mais rapidamente e acessar o documento XML quando chegar ao ponto em que deseja ver o documento completo. Na verdade, tive que voltar e fazer isso com vários aplicativos em que as pessoas tentaram usar o tipo de dados XML como um campo muito consultado e os dados cresceram até o ponto em que a consulta ficou muito lenta.

Eu usei campos do tipo XML principalmente para fins de registro relacionados a serviços da Web ASMX ou serviços WCF. Você pode salvar a solicitação ou as mensagens de resposta.

Na maioria das vezes, você salva o XML no banco de dados para fins de referência - não para sua atividade comercial normal (para não consultá-lo a cada 5 segundos a partir do código). Se você estiver fazendo isso, determine os campos que você normalmente consulta ou usa na maioria das vezes e crie colunas separadas para eles. Dessa forma, ao salvar o XML no banco de dados, você pode extrair esses campos e salvá-los nas colunas correspondentes. Mais tarde, ao recuperá-los, você não precisaria consultar o documento XML; basta usar as colunas criadas para esse fim.

Estes são os cenários que vêm à mente imediatamente quando se considera quais condições precisariam existir para permitir campos Xml no Sql Server:

• dados binários codificados para intercâmbio, nos quais você deseja controle do recurso como ácido
• fragmentos de documentos que serão reconstituídos no todo usando informações dinâmicas
• documentos enviados pelo usuário ou fragmentos que você deseja isolar e, pelo menos de forma provisória, mantenha diretamente o sistema de arquivos.

Uso XML extensivamente em aplicativos cliente-servidor para salvar dados estruturados em uma única chamada para o banco de dados. Como exemplo, faça uma fatura com linhas detalhadas. É simples fazer com que o cliente serialize o objeto de negócios em XML e passe para um processo armazenado em uma única chamada. O proc decide se uma inserção ou atualização é necessária; ele pode obter o ID da fatura pai (uma coluna de identidade) para atribuir aos registros detalhados, tudo dentro de uma transação do servidor e sem que o cliente precise fazer várias viagens de ida e volta. Não preciso de mais ou menos 20 parâmetros para especificar o registro do cabeçalho e não preciso fazer uma chamada para cada linha da fatura. Além disso, muitas vezes é possível fazer alterações no esquema ou introduzir log / auditoria, sem precisar tocar no cliente.