Parfois, lors de la création d’une requête avec l’explorateur de données, vous trouverez des codes utilisés dans les résultats plutôt que leurs équivalents textuels. Le champ a souvent une clé dans l’arborescence de l’explorateur de données, mais ceux-ci n’ont pas tendance à être aussi utiles en ce qui concerne les résultats (sauf si vous avez réussi à tous les mémoriser 
)
Il y a quelques éléments que vous pouvez utiliser pour les rendre plus agréables à l’œil et beaucoup plus facilement partageables avec d’autres.
Tout d’abord…
VALUES
La première requête a été créée pour extraire toutes les notifications qu’un utilisateur avait reçues pour un sujet particulier, mais, au lieu de simplement afficher le code notification_type, VALUES est utilisé pour créer une table temporaire et mapper chacun à ses contreparties beaucoup plus lisibles par l’homme :
-- Définir les paramètres pour user_id et topic_id
-- [params]
-- user_id :user_id
-- topic_id :topic_id
-- Créer une Common Table Expression (CTE) nommée ntypes
-- Cette CTE mappe les noms de types de notification à leurs ID correspondants
WITH ntypes(notification_type, notification_type_id) AS (
VALUES
-- Définir les paires de types de notification et leurs ID correspondants
('mentioned', 1),
('replied',2),
('quoted',3),
('edited', 4),
('liked', 5),
('private_message', 6),
('invited_to_private_message', 7),
('invitee_accepted', 8),
('posted', 9),
('moved_post', 10),
('linked', 11),
('granted_badge', 12),
('invited_to_topic', 13),
('custom', 14),
('group_mentioned', 15),
('group_message_summary', 16),
('watching_first_post', 17),
('topic_reminder', 18),
('liked_consolidated', 19),
('post_approved', 20),
('code_review_commit_approved', 21),
('membership_request_accepted', 22),
('membership_request_consolidated', 23),
('bookmark_reminder', 24),
('reaction', 25),
('votes_released', 26),
('event_reminder', 27),
('event_invitation', 28),
('chat_mention', 29),
('chat_message', 30),
('chat_invitation', 31),
('chat_group_mention', 32),
('chat_quoted', 33),
('assigned', 34),
('question_answer_user_commented', 35),
('watching_category_or_tag', 36),
('new_features', 37),
('admin_problems', 38),
('following', 800),
('following_created_topic', 801),
('following_replied', 802),
('circles_activity', 900)
)
-- Interroger la table notifications (alias n), en la joignant avec la CTE ntypes sur la base de notification_type
SELECT user_id, ntypes.notification_type, read, topic_id, created_at
FROM notifications n
JOIN ntypes
ON n.notification_type = ntypes.notification_type_id
-- Filtrer les notifications pour n'inclure que celles appartenant à un utilisateur spécifique et à un sujet spécifique
WHERE user_id = :user_id
AND topic_id = :topic_id
-- Trier les notifications résultantes par ordre décroissant de timestamp created_at
ORDER BY created_at DESC
L’utilisation de VALUES est utile lorsque la liste est longue car elle peut rendre la requête plus facile à lire. Elle vous permet également de lier la nouvelle table temporaire qu’elle crée à une autre, ce qui peut être très pratique. La table temporaire peut également contribuer à améliorer l’efficacité par rapport à une série d’instructions CASE.
Ce qui nous amène au second…
CASE
Alternativement, si la liste est beaucoup plus petite, vous pouvez également utiliser CASE pour un effet similaire. Voici un exemple pour post_type :
-- [params]
-- topic_id :topic_id
SELECT p.id AS post_id,
-- Commencer l'instruction CASE pour mapper les codes numériques de post_type à des descriptions textuelles
CASE
WHEN post_type = 1 THEN 'regular'
WHEN post_type = 2 THEN 'moderator_action'
WHEN post_type = 3 THEN 'small_action'
WHEN post_type = 4 THEN 'whisper'
END
FROM posts p
WHERE p.topic_id = :topic_id
ORDER BY created_at DESC
Ces exemples de requêtes peuvent ne pas être très utiles en eux-mêmes, mais servent davantage à démontrer les principes. J’espère qu’ils vous aideront, mais si vous avez des questions, n’hésitez pas à les poser ci-dessous.