Je veux utiliser une clause dans les lignes de "cas" quand ... puis 1 autre 0 extrémité "dans une instruction SELECT. La partie délicate est que j'en ai besoin pour fonctionner avec "valeur dans @list".
Si je code dure la liste Ça marche bien - et fonctionne bien: P>
-- @AvailableValues would be a list (array) of strings.
DECLARE
@AvailableValues ???
SELECT
@AvailableValues = ???
FROM
lookup_table
SELECT
CASE WHEN t.column_a IN @AvailableValues THEN 1 ELSE 0 END AS priority
, t.column_b
, t.column_c
FROM
table AS t
ORDER BY
priority DESC
4 Réponses :
Vous pouvez utiliser une variable dans une clause dans code>, mais pas dans la manière dont vous essayez de faire. Par exemple, vous pouvez le faire: declare @i int
declare @j int
select @i = 10, @j = 20
select * from YourTable where SomeColumn IN (@i, @j)
Ouais, eh bien, j'ai essayé d'utiliser une solution en ligne en fonction d'une variable de table, mais la performance était terrible. Dans le passé, j'ai toujours utilisé des variables de table à un bon effet (en termes de performance), mais cela ne fonctionne pas cette fois-ci. Acclamations pour la réponse cependant.
La solution que nous sommes finalement venu incorporé l'exemple de code que vous avez fourni (à côté d'un autre autre changement que nous avons apporté sur les types de données de colonne). Ce n'est pas la solution la plus flexible / maintenable, mais parce que nous n'utilisons que un petit nombre de variables dans la clause dans la clause dans la clause et cela ne change pas, nous avons réussi à obtenir la performance que nous recherchions avec cette approche.
Cela pourrait être le long des lignes de ce dont vous avez besoin.
Notez que cela suppose que vous avez des autorisations et que les données d'entrée ont été désinfectées.
Je crois comprendre que cela perdrait la performance car il n'y aurait aucun plan d'exécution. Quelqu'un peut-il confirmer / nier / améliorer ma compréhension ici? À votre santé.
Je ne suis pas sûr de cela pour être parfaitement honnête. [Preuve anecdotique :-) - Je l'ai déjà utilisée dans certaines conditions avec littéralement des millions de lignes et que vous n'avez pas remarqué de problèmes de performance pariculaire.] Il devrait être assez facile à tester à partir de votre scénario décrit.
4Guysfromrolla.com/wtbtech/sqlguru/q120899-2.shtml - "Commençant avec SQL 7.0, il y a un petit processus pratique appelé sp_executesql qui acceptera des requêtes paramétrées. Il tentera également de réutiliser des plans de requête, de sorte que si vous exécutez la même déclaration plusieurs fois, vous obtiendrez une requête réutilisée plan." Apparemment, vous ne perdrez que des analyses de temps et de compilation.
Les recompilations fréquentes entraîneraient des performances à souffrir, mais le temps supplémentaire impliqué pourrait être minute (+12 ms ou similaire) - test et voir, cela dépend de la complexité de la requête. Et essayez SP_EXecutesQL, en fonction de la complexité de la requête, cela peut permettre de meilleures performances.
Nous avons fini par une autre solution, mais vos réponses sont bonnes à savoir.
Basé sur votre mise à jour et en supposant que la table de recherche est petite, je suggère d'essayer quelque chose comme ce qui suit: (vous ne pouvez pas référencer l'alias de colonne "Priorité" dans la commande par Clause. Alternativement, vous pouvez utiliser la position ordinale comme suit: mais ce n'est généralement pas recommandé.) tant que la table de recherche est petite Cela devrait vraiment courir assez rapidement - mais votre commentaire implique que c'est une très grande table, ce qui pourrait ralentir la performance. comme pour n [var] char contre int, oui, les entiers seraient plus rapide, si seulement parce que la CPU a moins d'octets à jongler autour ... qui ne pose aucun problème lors du traitement d'un lot de lignes, donc cela vaut la peine d'être essayé.
En fait, l'utilisation d'une join gauche a été la première technique que j'ai essayée cependant que nous avions des problèmes de performance ici aussi. Après avoir passé du temps sur la solution, il est devenu évident que nous devons faire une optimisation sur nos index - si les tables étaient mieux indexées, je pense que cette solution aurait été parfaite. En tant que note latérale, vous pouvez faire référence à une «priorité» dans l'ordre (j'ai pu). Cheer, Zac
Tu as raison. C'est vrai pour le groupe par, ce qui me fait toujours me gâcher.
J'ai résolu ce problème en utilisant une fonction Charindex. Je voulais transmettre la chaîne en tant que paramètre unique. J'ai créé une chaîne avec des virgules de premier plan et de fuite pour chaque valeur que je voulais tester pour. Ensuite, j'ai concatéré des virgules de premier plan et de la fuite à la chaîne que je voulais voir si était "dans" le paramètre. À la fin, j'ai vérifié pour Charindex> 0 Vous pouvez également le faire dans la clause WHERE P> WHERE CHARINDEX(','+ISMAT.PROFIT_CENTER+',',@CTSPST_Profit_Centers) > 0
Jetez un coup d'œil à l'article d'Erland Sommarskog ici: Les tableaux et listes de SQL Server 2005 et au-delà de pour les versions 2000 et 2008, regardez ici: Sommarskog.se/arrays -in-sql.html
Je dois plus aller ici que
Sélectionnez Count (*) de MyTable où MyColumn In (Sélectionnez LookupValue à partir de Lameuse) . Publiez la requête complète et quelqu'un aidera à l'optimiser.@Sawyer - Vous utilisez déjà des variables de table dans le SP, avait des problèmes de performance ici.
@Philip Kelly, j'ai mis à jour les exemples pour refléter ce que j'essaie de faire mieux.