Eu havia feito perguntas sobre consultas XML com tag que não diferencia maiúsculas de minúsculas anteriormente e também encontrei uma solução. Mas também encontrei outra solução. Então a mesa era algo como
DECLARE @myTable TABLE ( yourXML XML )
INSERT INTO @myTable SELECT '<z><a><b>1</b><c>2</c></a></z>'
INSERT INTO @myTable SELECT '<Z><A><b>1</b><c>2</c></A></Z>'
E todas as soluções abaixo retornam o que eu queria (tag que não diferencia maiúsculas de minúsculas)
-----Solution 1----------
SELECT * FROM @myTable WHERE ( [yourXML].exist('for $x in /*[lower-case(local-name(.)) = "z"]/*[lower-case(local-name(.)) = "a"] where ( ($x/*[lower-case(local-name(.)) = "b"][1]) = 1 ) return $x')>0 )
-------------------------
-----Solution 2----------
SELECT * FROM @myTable
WHERE
(CONVERT(XML,LOWER(CONVERT(VARCHAR(MAX),[yourXML]))).exist('for $x in /z/a where ( ($x/b[1]) = 1 ) return $x')>0 )
-------------------------
-----Solution 3----------
SELECT * FROM @myTable WHERE
([yourXML].exist('for $x in (/Z/A,/z/a) where ( ($x/b[1],$x/B[1]) = 1 ) return $x') > 0 )
-------------------------
Agora eu quero saber qual é o melhor para usar considerando todos os seus comandos X-query (suporte para value(),exist(),count(),query() etc), Performance,Efficiency etc.
Você mesmo pode facilmente testar o desempenho.
Crie uma tabela regular na qual você possa testar suas consultas.
Adicione algumas linhas que lhe darão uma correspondência.
Adicione um monte de linhas que não corresponderão em diferentes partes do XML.
Use SET STATISTICS IO (Transact-SQL) e SET STATISTICS TIME (Transact-SQL) e execute suas consultas no SQL Server Management Studio.
Alterne para a guia de mensagens e avalie o tempo de execução e as leituras necessárias.
Presumivelmente, você tem dados melhores em seu banco de dados para testar. A característica de desempenho mudará dependendo da estrutura real do XML com a qual você deve lidar no mundo real.
Uma observação lateral é que suas consultas não são equivalentes.
O primeiro é facilmente adaptado para nomes de elementos mais longos.
A segunda consulta altera o conteúdo dos elementos, não apenas os nomes dos elementos.
A terceira consulta realmente não lida com nomes de elementos que não diferenciam maiúsculas de minúsculas, apenas enumera todos os nomes de elementos possíveis que, neste caso, são diferentes apenas nos casos. Se você quisesse lidar, digamos, um nome de elemento de 3 letras com sua terceira solução, você teria 8 (eu acho) permutações diferentes para lidar.
Adicionei uma quarta solução, principalmente porque é curta e bonita, que tem as mesmas limitações da terceira solução. Nas minhas medições, é um pouco mais rápido do que usar o FLWOR.