Estou em uma situação em que estou recebendo uma lista (potencialmente bastante longa) de "entidades de correspondência", cada uma contendo dados do usuário para correspondência, juntamente com um ID exclusivo para essas informações de correspondência. Os dados reais dos usuários correspondentes, juntamente com o ID exclusivo dessa correspondência, precisam ser retornados da minha consulta SQL. Então, digamos que eu tenha recebido duas entidades para tentar fazer a correspondência de usuários, ambas tentando fazer a correspondência de números de telefone com o número de telefone de um usuário; Eu poderia corresponder a qualquer usuário associado às entidades enviadas junto com o ID exclusivo da "entidade de correspondência" usando uma união como esta ( client_handle
é o ID exclusivo enviado):
SELECT
[client_handle] = 'axtwe-wasst',
[user_id],
[email],
[mobile_no],
[firstname],
[surname]
FROM
[dbo].[vAPP_UsersActive]
WHERE
[mobile_no] in ('+44 7747 122123', '+44 7904 223323')
UNION
SELECT
[client_handle] = 'zjfft-albwq',
[user_id],
[email],
[mobile_no],
[firstname],
[surname]
FROM
[dbo].[vAPP_UsersActive]
WHERE
[mobile_no] in ('+44 7758 444111', '+44 7758 444222', '+44 7758 444333')
O problema com esse método é que ele pode resultar em um número muito grande de UNION
s se um grande número de entidades de correspondência forem enviadas para mim. 1000 entidades de correspondência enviadas resultariam em 999 UNION
s. Isso é realmente um problema em termos de desempenho e existe uma maneira melhor de alcançar o resultado que desejo? Como alternativa, eu poderia simplesmente percorrer cada entidade de correspondência enviada e executar uma consulta para corresponder a cada uma, mas teria 1.000 consultas separadas se 1.000 entidades de correspondência fossem enviadas, o que parece ainda pior.
Esquematicamente:
PS.
[parameters group]
não é usado - nos dados de origem mostrados, é excessivo, mas pode ser útil na tarefa real (se for o caso, GROUP BY em vez de DISTINCT deve ser usado).O que acabei fazendo no final foi passar JSON representando os diferentes conjuntos de consultas e dividi-los em uma tabela usando
OPENJSON
. Isso realmente torna a consulta simples o suficiente para que ela nem precise estar em um procedimento armazenado ou criar um arquivo temporário. table, comoOPENJSON
pode ser usado diretamente em umaJOIN
consulta, sendo uma função com valor de tabela:... onde a
@jsonQuery
variável é passada com um valor como:O código de chamada primeiro precisa nivelar as consultas com o mesmo
UniqueId
em várias "linhas de consulta" como visto no JSON acima e, em seguida, nivelar as correspondências retornadas com um dicionário cuja chave é oUniqueId
.