J'ai une table avec de nombreux identifiants et de nombreuses dates associées à chaque identifiant, et même quelques identifiants sans date. Pour chaque combinaison d'identité et de date, je souhaite sélectionner l'identifiant, la date et la date la plus forte suivante associée à ce même ID ou NULL comme date suivante, si personne n'existe.
Table d'échantillon: P>
ID Date Next_Date 1 5/1/10 6/1/10 1 6/1/10 7/1/10 1 7/1/10 2 6/15/10 3 8/15/10 3 8/15/10 4 4/1/10 4/15/10 4 4/15/10
3 Réponses :
sélectionner
identifiant,
Date,
( Sélectionner une date
De la table T1
Où t1.date> t2.Date
Commander par t1.date limite 1)
De la table T2
Si votre dB est oracle, vous pouvez utiliser plomb () et décalage () code> fonctions. SELECT id, date,
LEAD(date, 1, 0) OVER (PARTITION BY ID ORDER BY Date DESC NULLS LAST) NEXT_DATE,
FROM Your_table
ORDER BY ID;
Le code ci-dessus produit une erreur pour moi - le 0 devrait être nul alors que Oracle SQL se plaint d'être un type de données incompatible (nombre au lieu de la date), ce qui fonctionne correctement: Sélectionnez ID, date, avance (date, 1, null) Over (partition par ordre d'identification par date desc nulles dernier) Next_Date, à partir de votre_table
id date NextDate ----------- ----------------------- ----------------------- 1 2010-05-01 00:00:00.000 2010-06-01 00:00:00.000 1 2010-06-01 00:00:00.000 2010-06-15 00:00:00.000 1 2010-07-01 00:00:00.000 2010-08-15 00:00:00.000 2 2010-06-15 00:00:00.000 2010-07-01 00:00:00.000 3 2010-08-15 00:00:00.000 NULL 3 2010-08-15 00:00:00.000 NULL 4 2010-04-01 00:00:00.000 2010-04-15 00:00:00.000 4 2010-04-15 00:00:00.000 2010-05-01 00:00:00.000 4 NULL NULL
Il est préférable d'utiliser la commande que des fonctions agrégées. Vous avez une grosse table surtout
@Andrii: Je ne peux pas parler d'autres DBS, mais sur SQL Server, cela ne devrait pas faire de différence. S'il y a un index, il est assez intelligent pour savoir que cela peut simplement lire la première rangée; S'il n'y a pas d'index, il doit analyser toute la table. En fait, avec une commande par elle pourrait être plus lente car il faudrait faire un tri (n * lg (n)) au lieu d'une analyse O (n).
Il s'agit d'un DB MSSQL avec la requête étant passée via un accès, ce qui signifie que la requête limite ne fonctionnerait de toute façon. La requête minorme ci-dessus a parfaitement fonctionné avec la légère addition d'ajout de myTable.id = mytablemin.id dans la déclaration où. La requête est un peu morose, mais il n'y a pas d'index sur le champ de date que j'utilise actuellement. Merci tout pour l'aide.