SQL fonction Row_Number() dans la Clause where
J'en ai trouvé une réponse à votre question avec le Row_Number()
fonction dans la clause where. Quand j'ai essayé une requête, je recevais le message d'erreur suivant:
"Msg 4108, Niveau 15, État 1, Ligne 1
Fenêtré fonctions ne peuvent apparaître dans la sélection ou des clauses ORDER BY."
Voici la requête que j'ai essayé. Si quelqu'un sait comment résoudre ce problème, s'il vous plaît laissez-moi savoir.
SELECT employee_id
FROM V_EMPLOYEE
WHERE row_number() OVER ( ORDER BY employee_id ) > 0
ORDER BY Employee_ID
ROW_NUMBER() OVER (ORDER BY employee_id) > 0
toujours évaluer àTRUE
- Oui, c'est vrai. Je ne suis pas inquiet à propos de l'état de fait, qui peut changer à tout moment. Je veux que la requête pour le travail d'abord, puis de la pensée de maintien de la rownumber entre 500 et 800... merci
- Pourquoi essayez-vous d'éviter d'utiliser une expression de table commune?
- Je ne suis pas un expert en SQL Server. Je suis en train d'aider une équipe dans un projet où ils sont confrontés à beaucoup de problèmes de performance. Ils sont à l'aide de fonctions définies par l'utilisateur et d'expressions de table communes. Dans celui de la table, ils ont seulement 5000 enregistrements, et si 5 utilisateurs accédant à une recherche, il prendre plus d'une minute pour récupérer. Quelques fois, il échoue et le temps. Donc, je vais essayer d'éviter de CTE et de l'Udf et essayer de venir avec un simple requête SQL qui peut résoudre les problèmes de performances.
- Salut à tous, Veuillez consulter le lien que j'ai posté ci-dessous les réponses à l'aide de la fonction row_number() d'une manière différente. Quelqu'un peut-il comparer ma requête initiale avec celle dans le lien? Apprécions l'aide..
Vous devez vous connecter pour publier un commentaire.
Pour contourner ce problème, enveloppez votre instruction select dans une expression de table commune, et puis vous pouvez interroger l'encontre de la CCE et de l'utilisation de la fenêtre de la fonction de résultats dans la clause where.
ROW_NUMBER()
dansWHERE
clause sans CTE 🙁Noter que ce filtre est redondant:
ROW_NUMBER()
commence à partir de1
et est toujours plus grande que0
.q
? Ça veut dire quoi?AS q
à la place, mais ce serait le travail soit).ORDER BY (SELECT 100)
et pouvez passer COMMANDE PAR BlahID à la fin.Je pense que vous voulez quelque chose comme ceci:
From V_EMPLOYEE) A
qui est d'ajouter Un alias.En réponse aux commentaires sur rexem réponse, quant à savoir si une ligne de vue ou de CTE serait plus rapide j'ai remanié les requêtes à utiliser un tableau, et tout le monde, avait à sa disposition: sys.objets.
La requête plans produits sont exactement les mêmes. Je dirais que dans tous les cas, l'optimiseur de requête produiraient le même plan, au moins dans le simple remplacement de la CTE avec vue intégrée ou vice versa.
Bien sûr, essayer vos propres requêtes sur votre propre système pour voir si il y a une différence.
Aussi,
row_number()
dans la clause where est une erreur courante dans les réponses données sur un Débordement de Pile. Logicalyrow_number()
n'est pas disponible jusqu'à ce que la clause select est traitée. Les gens oublient que et quand ils répondent sans tester la réponse, la réponse est parfois mal. (A la charge, je l'ai moi-même été coupable d'.)À l'aide de CTE (SQL Server 2005+):
L'aide de vue intégrée/Non-CTE Alternative:
SQL Server
,CTE
's et en ligne points de vue sont la même chose et ont les mêmes performances. Lorsque la non-déterministe fonctions sont utilisées dans unCTE
, son réévaluées à chaque appel. On a à faire usage de ruse à la force materializationof unCTE
. Voir ces articles dans mon blog: explainextended.com/2009/07/28/... explainextended.com/2009/05/28/generating-xml-in-subqueriesbasé sur les OP de la réponse à la question:
"méthode 1", c'est comme l'OP de la requête à partir de la question liée, et la "méthode 2", c'est comme la requête à partir de la réponse choisie. Vous avez eu à regarder le code lié à ce réponse pour voir ce qui se passait réellement, puisque le code de la réponse choisie a été modifié pour le faire fonctionner. Essayez ceci:
De SORTIE:
J'ai envie de toutes les réponses montrant l'utilisation d'un CTE ou Sous-Requête sont suffisantes correctifs pour cela, mais je ne vois pas de rentrer dans le cœur de pourquoi l'OP a un problème. La raison pour laquelle ce que l'OP a suggéré de ne pas travailler est due à la logique de traitement des requêtes d'ordre ici:
Je crois que cela contribue à la réponse grandement, parce qu'il explique pourquoi les questions de ce genre se produire.
WHERE
est toujours traitée avantSELECT
faire un CTE ou d'un Sous Requête nécessaire pour de nombreuses fonctions. Vous verrez beaucoup dans SQL Server.