2009-03-25 8 views
2

J'utilise cette requête SQL pour commander une liste d'enregistrements par date dans une page php.sélection de l'enregistrement suivant dans une liste triée par date

SELECT ARTICLE_NO, USERNAME, ACCESSSTARTS, ARTICLE_NAME FROM table WHERE upper(ARTICLE_NAME) LIKE % x % ORDER BY str_to_date(ACCESSSTARTS, '%d/%m/%Y %k:%i:%s'); 

Cela fonctionne très bien.

Dans une page php différente, je souhaite pouvoir supprimer cet enregistrement et afficher le suivant dans la liste. La requête J'utilise pour ce faire est:

SELECT ARTICLE_NO FROM auctions1 WHERE str_to_date(ACCESSSTARTS, '%d/%m/%Y %k:%i:%s') > (SELECT str_to_date(ACCESSSTARTS, '%d/%m/%Y %k:%i:%s') FROM table WHERE ARTICLE_NO =".$pk.") ORDER BY str_to_date(ACCESSSTARTS, '%d/%m/%Y %k:%i:%s') LIMIT 1"; 

Le problème que je semblons avoir, parce qu'il ya beaucoup de dossiers avec la même date, tout enregistrement du groupe d'enregistrements à la même date sera choisie , pas le même dans la liste.

Comment puis-je sélectionner l'enregistrement suivant renvoyé à partir du même jeu de résultats que la première requête? La première requête renvoie toujours le même ordre, donc je ne sais pas pourquoi la deuxième requête semble avoir un ordre différent.

modifier:

J'ai essayé d'utiliser des conseils Quassnoi. La première requête J'utilise maintenant est:

SELECT ARTICLE_NO, USERNAME, ACCESSSTARTS, ARTICLE_NAME, 
     date_format(str_to_date(ACCESSSTARTS, '%d/%m/%Y %k:%i:%s'), '%d %m %Y') AS shortDate 
FROM AUCTIONS1 
WHERE upper(ARTICLE_NAME) LIKE % x % 
ORDER BY 
     str_to_date(ACCESSSTARTS, '%d/%m/%Y %k:%i:%s'), article_no limit 0, 10 

Et la deuxième requête, comme le suggère Quassnoi est:

SELECT ARTICLE_NO 
FROM auctions1 
WHERE (str_to_date(ACCESSSTARTS, '%d/%m/%Y %k:%i:%s'), article_no) > 
     (
     SELECT str_to_date(ACCESSSTARTS, '%d/%m/%Y %k:%i:%s'), article_no 
     FROM auctions1 
     WHERE ARTICLE_NO = xxx 
     ) 
ORDER BY 
     str_to_date(ACCESSSTARTS, '%d/%m/%Y %k:%i:%s'), article_no 
LIMIT 1 

Je copié cette requête en faisant écho à ce à travers ma page php, et simplement placé xxx à la place de l'article_no qui était présent. Cela correspond parfaitement au premier exemple de code, mais les résultats sont les mêmes que le code que j'utilisais dans ma question initiale.

Edit2:

Ceci est la requête utilisée pour obtenir le jeu de résultats d'origine:

SELECT ARTICLE_NO, USERNAME, ACCESSSTARTS, ARTICLE_NAME, date_format(str_to_date(ACCESSSTARTS, '%d/%m/%Y %k:%i:%s'), '%d %m %Y') AS shortDate FROM auctions1 WHERE upper(ARTICLE_NAME) LIKE '%o%' ORDER BY str_to_date(ACCESSSTARTS, '%d/%m/%Y %k:%i:%s'), article_no limit 0, 10; 

Quels sont les résultats de ces données, ce qui est bien:

ARTICLE_NO USERNAME ACCESSSTARTS  ARTICLE_NAME      shortDate 
160288212077 5864_australen 30/09/2008 05:22:30  DON ED HARDY TIGER JACKE WEISS XL    30 09 2008 
220288566257 fashionticker1 01/10/2008 16:39:12  Ed Hardy Tank Top Lila Neu & OVP Gr. L   01 10 2008 
280273115680 mulle15  01/10/2008 16:42:38  Ed Hardy, T-Shirt,Destroy, schwarz, Gr.L  01 10 2008 
280273115991 mulle15  01/10/2008 16:43:54  Ed Hardy, T-Shirt,Destroy, schwarz, Gr.XL  01 10 2008 
280273116224 mulle15  01/10/2008 16:44:59  Ed Hardy, T-Shirt,Destroy, schwarz, Gr.XXL  01 10 2008 
280273118653 mulle15  01/10/2008 16:54:50  Ed Hardy, T-Shirt,King Snoopy,chocolate, Gr.M  01 10 2008 
120312402767 lieschenjuli 01/10/2008 16:56:12  Badehose Shorts Ed Hardy L    01 10 2008 
280273119206 mulle15  01/10/2008 16:56:47  Ed Hardy, T-Shirt,King Snoopy,chocolate, Gr.XL  01 10 2008 
280273119489 mulle15  01/10/2008 16:57:49  Ed Hardy, T-Shirt,King Snoopy,chocolate, Gr.XXL  01 10 2008 
160288777155 bonifatzius1 01/10/2008 16:58:33  Ed Hardy Bomberjacke Gr. L Jacke für Damen oder H... 01 10 2008 

Le problème est, si j'effectue cette requête:

SELECT ARTICLE_NO 
FROM auctions1 
WHERE (str_to_date(ACCESSSTARTS, '%d/%m/%Y %k:%i:%s'), article_no) > 
     (
     SELECT str_to_date(ACCESSSTARTS, '%d/%m/%Y %k:%i:%s'), article_no 
     FROM auctions1 
     WHERE ARTICLE_NO =160288212077 
     ) 
ORDER BY 
     str_to_date(ACCESSSTARTS, '%d/%m/%Y %k:%i:%s'), article_no 
LIMIT 1; 

Le ceci renvoie 280273112610, quand 220288566257 est ce qui devrait être retourné

+0

S'il vous plaît poster quelques exemples de données de vos tables et ce que vous souhaitez obtenir en conséquence. – Quassnoi

+0

ok, publier maintenant. –

+0

Bien sûr, j'ai oublié d'ajouter LIKE condition. Voir la première requête dans mon message. – Quassnoi

Répondre

1
SELECT ARTICLE_NO 
FROM auctions1 
WHERE upper(ARTICLE_NAME) LIKE '% x %' 
     AND (str_to_date(ACCESSSTARTS, '%d/%m/%Y %k:%i:%s'), article_no) > 
     (
     SELECT str_to_date(ACCESSSTARTS, '%d/%m/%Y %k:%i:%s'), article_no 
     FROM auctions1 
     WHERE ARTICLE_NO = @pk 
     ) 
ORDER BY 
     str_to_date(ACCESSSTARTS, '%d/%m/%Y %k:%i:%s'), article_no 
LIMIT 1 

Notez que votre resultset d'origine:

SELECT ARTICLE_NO, USERNAME, ACCESSSTARTS, ARTICLE_NAME 
FROM auctions1 
WHERE upper(ARTICLE_NAME) LIKE % x % 
ORDER BY 
     str_to_date(ACCESSSTARTS, '%d/%m/%Y %k:%i:%s'); 

ne garantit pas l'ordre de ligne stable dans un ACCESSSTARTS. Vous devez ajouter PRIMARY KEY à la clause ORDER BY, comme ceci:

SELECT ARTICLE_NO, USERNAME, ACCESSSTARTS, ARTICLE_NAME 
FROM auctions1 
WHERE upper(ARTICLE_NAME) LIKE % x % 
ORDER BY 
     str_to_date(ACCESSSTARTS, '%d/%m/%Y %k:%i:%s'), article_no. 

(Je suppose ARTICLE_NO est le PRIMARY KEY de votre table)

Votre rowset d'origine, en fonction de la méthode d'accès qu'il utilise, les retours lignes dans l'ordre du tableau dans l'ordre de l'index.

Vous avez vraiment, vraiment, vraiment besoin de changer votre jeu de lignes d'origine pour utiliser l'ordre stable.

Mais si vous ne pouvez pas le faire pour une raison quelconque, vous pouvez effectuer les opérations suivantes:

SELECT ARTICLE_NO, USERNAME, ACCESSSTARTS, ARTICLE_NAME, 
FROM (
     SELECT @c := NULL 
     ) vars, 
     auctions1 
WHERE upper(ARTICLE_NAME) LIKE % x % 
     AND CASE WHEN ARTICLE_NO = $PK THEN @с := 0 ELSE 0 END IS NOT NULL 
     AND (@c := @c + 1) = 2 
ORDER BY 
     str_to_date(ACCESSSTARTS, '%d/%m/%Y %k:%i:%s'); 
LIMIT 1 

Cette requête est moins efficace et repose en grande partie sur des faits que cette requête utilisera exactement la même méthode d'accès que votre original question.

Vous ne comptez normalement pas sur ce fait, car la méthode d'accès peut changer à tout moment.

Si vous voulez un code clair et sain, ajoutez le ARTICLE_NO en ORDER BY et profitez de la requête que j'ai publiée en premier.

+0

Il en résulte le même comportement que dans mon message. L'enregistrement suivant de ma liste d'enregistrements n'est pas sélectionné, mais un enregistrement avec la même date dans un ordre différent est sélectionné. –

+0

HI Quassnoi, merci pour la clarification, mais elle échoue toujours. J'ai posté les requêtes mises à jour que j'utilise dans ma question. –

+0

modifié avec les nouvelles infos –

1

Vous pourriez essayer également de commander vos résultats par ARTICLE_NO. Faites simplement:

... ORDER BY str_to_date(ACCESSSTARTS, '%d/%m/%Y %k:%i:%s'), ARTICLE_NO ... 

De cette façon, les deux ensembles de résultats doivent avoir exactement le même ordre. Dans les deux cas, l'enregistrement suivant sera l'enregistrement avec le moins bon ARTICLE_NO avec une date postérieure.

Salutations

Sacher

+0

les champs ARTICLE_NO sont complètement arbitraires, mais je vais essayer ceci. –

0

Ceci est parfaitement logique. Vous avez une condition sur ARTICLE_NAME dans la première requête qui est manquante dans la deuxième requête - la deuxième requête renvoie plus de lignes que la première. Retirez la LIMITE et vous verrez. La deuxième condition d'ordre est également une bonne idée, même si le nombre est arbitraire.

Questions connexes