Comment obtenir au mieux 3 images antérieures et 3 images postérieures dans une requête MySQL?

Question

Je vais expliquer brièvement ce que je veux accomplir d'un point de vue fonctionnel. Je travaille sur une galerie d'images. Sur la page qui affiche une seule image, je souhaite que la barre latérale affiche les vignettes des images téléchargées par le même utilisateur. Au maximum, il devrait y avoir 6, 3 qui ont été postés avant l'image principale actuelle, et 3 qui ont été postés après l'image principale. Vous pouvez le voir comme un flux d'images par le même utilisateur à travers lequel vous pouvez naviguer. Je crois que Flickr a une chose similaire.

Techniquement, ma table d'image a un ID auto-incrémenté, un identifiant d'utilisateur et un champ date_uploaded, parmi beaucoup d'autres colonnes. Quels seraient vos conseils sur la façon de mettre en œuvre une telle requête? Puis-je combiner ceci en une seule requête? Existe-t-il des utilitaires MySQL pratiques qui peuvent gérer les offsets et autres? PS: Je préfère ne pas créer de colonne "rank" supplémentaire, car cela rendrait difficile la gestion des suppressions. En outre, l'utilisation de l'identifiant d'auto-incrémentation semble risquée, je pourrais le changer pour un GUID plus tard. Enfin, je suis bien sûr à la recherche d'une requête performante et évolutive.

Je sais que je demande beaucoup, mais il semble plus simple que c'est?

Answer 1

La requête pourrait ressembler à ceci.
Avec un index ID_utilisateur + ID_image (et éventuellement des champs supplémentaires à des fins de couverture), cela devrait fonctionner relativement bien.

SELECT field1, field2, whatever 
FROM myTable 
WHERE UserID = some_id 
    -- AND image_id > id_of_the_previously_first_image 
ORDER BY image_id 
LIMIT 7; 

Pour faciliter la mise à l'échelle, vous devez envisager d'utiliser une valeur LIMIT plus grande et de mettre en cache en conséquence.

Modifier (répondant à des remarques/questions):
L'indice combiné ...
est fait de plusieurs domaines, en particulier

CREATE [UNIQUE] INDEX UserId_Image_id_idx 
    ON myTable (UserId, image_ida [, field1 ...]) 

Notez que les éléments facultatifs de cette requête sont entre parenthèses ([]). Je suppose que la contrainte UNIQUE serait une bonne chose. Les champs "covering" supplémentaires (field1, ...) peuvent être bénéficiaires, mais dépendent de la "largeur" ​​de ces champs supplémentaires ainsi que des configurations générales d'utilisation et d'installation (puisque les [grands] index ralentissent INSERTs/UPDATEs/DELETE, on peut souhaiter limiter le nombre et la taille de tels index, etc.)

Un tel "type" de données d'index n'est ni numérique ni une chaîne etc. Il est simplement constitué des types de données individuels. Par exemple, si UserId est VARCHAR (10) et image_id est INT, l'indice résultant utiliserait ces deux types pour les critères de recherche sous-jacents, à savoir

... Où UserId = 'JohnDoe' ET image_id> 12389

en d'autres termes, il n'est pas nécessaire de combiner ces critères en une seule clé.

Sur image_id
quand vous dites image_id, vous voulez dire l'utilisateur combiné/id d'image, non?
Non, je veux dire seulement image_id. Je suppose que ce champ est un champ séparé dans la table. L'ID utilisateur est pris en charge dans l'autre prédicat de la clause WHERE. L'écriture de la question originale indique que ce champ est généré automatiquement, et je suppose que nous pouvons compter sur ce champ pour le tri. Alternativement nous pourrions compter sur d'autres champs tels que le timestamp quand l'image a été téléchargée et tel.

En outre, après coup, si commandé par un [plus en plus de façon monotone] image_id ou par le Timestamp_of_upload, on peut vouloir utiliser un pour DESC, pour montrer la dernière « substance » en premier.