Construire des requêtes SQL avec l'IA | Original, traduit par l'IA

Home 2025.07

Schéma de base de données (PostgreSQL):

CREATE TABLE users (
    id SERIAL PRIMARY KEY,
    username VARCHAR(50) UNIQUE NOT NULL,
    email VARCHAR(255) UNIQUE NOT NULL,
    password_hash VARCHAR(255) NOT NULL,
    first_name VARCHAR(100),
    last_name VARCHAR(100),
    date_of_birth DATE,
    gender VARCHAR(10),
    phone_number VARCHAR(20),
    address TEXT,
    city VARCHAR(100),
    state VARCHAR(100),
    country VARCHAR(100),
    zip_code VARCHAR(20),
    created_at TIMESTAMP WITH TIME ZONE DEFAULT CURRENT_TIMESTAMP,
    updated_at TIMESTAMP WITH TIME ZONE,
    last_login TIMESTAMP WITH TIME ZONE,
    is_active BOOLEAN DEFAULT TRUE,
    role VARCHAR(50),
    profile_picture_url VARCHAR(255),
    bio TEXT,
    failed_login_attempts INTEGER DEFAULT 0,
    account_balance NUMERIC(10, 2) DEFAULT 0.00
);

ci-dessus est la base de données postgre, ci-dessous est la définition de la table. voici les instructions de requête en langage naturel.

je veux obtenir certains utilisateurs dont le prénom est andy, créés_ à peu près le jour du mois dernier, et qui ont 20 ans en 2025, et dont le dernier_connexion ressemble à la semaine dernière, donnez-moi le sql pour interroger de tels utilisateurs

Requête SQL générée :

SELECT *
FROM users
WHERE first_name ILIKE 'andy'
  AND CAST(created_at AS DATE) BETWEEN
      (CURRENT_DATE - INTERVAL '1 MONTH' - INTERVAL '1 DAY')
      AND
      (CURRENT_DATE - INTERVAL '1 MONTH' + INTERVAL '1 DAY')
  AND EXTRACT(YEAR FROM AGE(date_of_birth)) = 20
  AND last_login >= CURRENT_TIMESTAMP - INTERVAL '7 DAYS';

Ci-dessous se trouve une définition de table PostgreSQL pour une table conversations qui pourrait être utilisée pour stocker les interactions des utilisateurs avec un système d’IA comme Grok. La table est conçue pour suivre les conversations, y compris l’utilisateur impliqué, le contenu de la conversation, les horodatages et les métadonnées pertinentes.

CREATE TABLE conversations (
    id SERIAL PRIMARY KEY,
    user_id INTEGER NOT NULL,
    title VARCHAR(255),
    conversation_type VARCHAR(50) DEFAULT 'chat',
    started_at TIMESTAMP WITH TIME ZONE DEFAULT CURRENT_TIMESTAMP,
    ended_at TIMESTAMP WITH TIME ZONE,
    status VARCHAR(50) DEFAULT 'active',
    message_count INTEGER DEFAULT 0,
    last_message_at TIMESTAMP WITH TIME ZONE,
    is_archived BOOLEAN DEFAULT FALSE,
    ai_model_version VARCHAR(100),
    total_tokens_used INTEGER DEFAULT 0,
    created_at TIMESTAMP WITH TIME ZONE DEFAULT CURRENT_TIMESTAMP,
    updated_at TIMESTAMP WITH TIME ZONE,
    FOREIGN KEY (user_id) REFERENCES users(id) ON DELETE CASCADE
);

Explication :

Cette table est conçue pour être flexible et peut être étendue en fonction des besoins spécifiques, comme le stockage des messages individuels dans une table messages séparée ou l’ajout de champs pour l’analyse de sentiment ou les balises de conversation. Faites-moi savoir si vous avez besoin d’une table connexe (par exemple, pour les messages) ou d’une requête pour interagir avec cette table !

Pour permettre à un frontend où les utilisateurs peuvent interroger leurs propres conversations en langage naturel (par exemple, “donnez-moi mes 5 dernières conversations” ou “conversations dont le titre contient le mot java”), vous devez vous assurer que la requête SQL restreint les résultats aux conversations de l’utilisateur authentifié. Cela implique d’incorporer l’identité de l’utilisateur (par exemple, user_id) dans la requête et de traduire l’entrée en langage naturel en conditions SQL. Ci-dessous se trouvent des exemples de requêtes et de requêtes SQL correspondantes pour la table conversations, en veillant à ce que les utilisateurs ne puissent accéder qu’à leurs propres données.

Considérations clés

Exemples de requêtes en langage naturel et de requêtes SQL

Requête 1 : “Donnez-moi mes 5 dernières conversations”

Exigences analysées :

Requête SQL :

SELECT *
FROM conversations
WHERE user_id = :authenticated_user_id
ORDER BY started_at DESC
LIMIT 5;

Requête 2 : “Conversations dont le titre contient le mot java”

Exigences analysées :

Requête SQL :

SELECT *
FROM conversations
WHERE user_id = :authenticated_user_id
  AND title ILIKE '%java%';

Notes d’implémentation pour le frontend

  1. Authentification de l’utilisateur :
    • Le frontend doit envoyer l’ID de l’utilisateur authentifié (par exemple, à partir d’un jeton JWT ou d’une session) à l’API backend.
    • Le backend doit valider le user_id et l’utiliser dans la clause WHERE pour filtrer les résultats.
  2. Traitement du langage naturel :
    • Utiliser un analyseur basé sur des règles simples ou un modèle d’IA (comme Grok) pour interpréter la requête en langage naturel et extraire :
      • Intention : Lister les conversations.
      • Filtres : Mots-clés (par exemple, “java”), tri (par exemple, “dernières”), ou limites (par exemple, “5”).
    • Par exemple, mapper “5 dernières” à ORDER BY started_at DESC LIMIT 5 et “titre contient le mot java” à title ILIKE '%java%'.
  3. Conception de l’API :
    • Créer un point de terminaison (par exemple, /api/conversations) qui accepte :
      • user_id : À partir de la session authentifiée.
      • query : L’entrée en langage naturel ou des paramètres structurés (par exemple, { filter: "title contains java" }).
    • Le backend traduit la requête en SQL, en veillant à ce que user_id soit toujours inclus dans la clause WHERE.
  4. Sécurité :
    • Ne jamais permettre aux utilisateurs d’entrer directement du SQL ou de modifier le filtre user_id.
    • Utiliser des requêtes paramétrées (par exemple, :authenticated_user_id) pour éviter les injections SQL.
    • Valider les entrées pour éviter les motifs malveillants dans les recherches ILIKE.
  5. Affichage du frontend :
    • Retourner des champs comme id, title, started_at, last_message_at et status pour afficher une liste de conversations.
    • Permettre des options de tri ou de filtrage dans l’interface utilisateur (par exemple, des menus déroulants pour “dernières” ou une entrée de texte pour la recherche de titre).

Exemple de flux de travail

  1. L’utilisateur se connecte, et le frontend récupère son user_id (par exemple, 123).
  2. L’utilisateur tape “donnez-moi mes 5 dernières conversations” dans une barre de recherche.
  3. Le frontend envoie une requête au backend : /api/conversations?user_id=123&query=5 dernières.
  4. Le backend analyse la requête, génère le SQL : 
    SELECT *
FROM conversations
WHERE user_id = 123
ORDER BY started_at DESC
LIMIT 5;
  5. Le backend retourne les résultats en JSON, et le frontend affiche les conversations.

Notes supplémentaires

Faites-moi savoir si vous avez besoin d’aide pour le code frontend, la configuration de l’API backend ou des exemples de requêtes supplémentaires !

Back Donate