SPARQL vs SQL

Deux langages, deux paradigmes : le match des requêtes de données

01

📖 Introduction

SQL (Structured Query Language) est le langage standard pour interroger les bases de données relationnelles depuis les années 1970. SPARQL (SPARQL Protocol and RDF Query Language) est le langage standard W3C pour interroger les graphes RDF depuis 2008.

💡 La différence fondamentale :
  • SQL interroge des tables (lignes et colonnes) avec un schéma fixe
  • SPARQL interroge des graphes (triplets sujet-prédicat-objet) avec un schéma flexible
02

🔤 Syntaxe comparée

📊 SQL

SELECT colonne1, colonne2
FROM table
WHERE condition
GROUP BY colonne1
ORDER BY colonne2;

Structure : SELECT, FROM, WHERE, JOIN, GROUP BY, HAVING, ORDER BY

🔍 SPARQL

SELECT ?variable1 ?variable2
WHERE {
  ?sujet ?predicat ?objet .
  FILTER(condition)
}
ORDER BY ?variable2

Structure : SELECT, WHERE (graphe de triplets), FILTER, OPTIONAL, UNION, ORDER BY

💡 Différence clé : SPARQL utilise des variables préfixées par ? (ex: ?personne) et exprime les patterns sous forme de triplets. SQL utilise des noms de colonnes explicites.
03

📝 Exemples concrets

Schéma de données : Personnes et leurs villes

-- Création des tables
CREATE TABLE Personne (
    id INT PRIMARY KEY,
    nom VARCHAR(100),
    age INT
);

CREATE TABLE Ville (
    id INT PRIMARY KEY,
    nom VARCHAR(100),
    pays VARCHAR(100)
);

CREATE TABLE Habite (
    personne_id INT,
    ville_id INT,
    FOREIGN KEY (personne_id) REFERENCES Personne(id),
    FOREIGN KEY (ville_id) REFERENCES Ville(id)
);

-- Requête : trouver les noms des personnes qui habitent à Paris
SELECT p.nom
FROM Personne p
JOIN Habite h ON p.id = h.personne_id
JOIN Ville v ON h.ville_id = v.id
WHERE v.nom = 'Paris';

-- Requête : trouver les personnes de plus de 30 ans
SELECT nom, age
FROM Personne
WHERE age > 30
ORDER BY age DESC;
# Données RDF (Turtle)
@prefix :  .
@prefix rdf:  .

:Alice a :Personne ;
    :nom "Alice" ;
    :age 28 ;
    :habite :Paris .

:Paris a :Ville ;
    :nom "Paris" ;
    :pays "France" .

# Requête : trouver les noms des personnes qui habitent à Paris
SELECT ?nom WHERE {
    ?personne a :Personne .
    ?personne :nom ?nom .
    ?personne :habite ?ville .
    ?ville :nom "Paris" .
}

# Requête : trouver les personnes de plus de 30 ans
SELECT ?nom ?age WHERE {
    ?personne a :Personne .
    ?personne :nom ?nom .
    ?personne :age ?age .
    FILTER(?age > 30)
}
ORDER BY DESC(?age)

Requête avancée : relations récursives

Problème : Trouver toutes les personnes qui sont "amis des amis" de Sophie.

SQL (récursif)

WITH RECURSIVE amis_cte AS (
    SELECT friend_id, 1 as niveau
    FROM Amis
    WHERE personne_id = (SELECT id FROM Personne WHERE nom = 'Sophie')
    
    UNION ALL
    
    SELECT a.friend_id, niveau + 1
    FROM Amis a
    JOIN amis_cte c ON a.personne_id = c.friend_id
    WHERE niveau < 3
)
SELECT DISTINCT p.nom
FROM amis_cte
JOIN Personne p ON amis_cte.friend_id = p.id;

⚠️ Syntaxe lourde, support variable selon SGBD

SPARQL (propriété)

SELECT ?nom WHERE {
    :Sophie :amis+ ?ami .
    ?ami :nom ?nom .
}

✅ Syntaxe élégante : :amis+ = un ou plusieurs sauts

:amis* = zéro ou plusieurs sauts

04

🔍 Quand utiliser SPARQL ?

✅ SPARQL excelle pour :

  • Données en graphe : relations complexes, multiples connexions
  • Schéma flexible : propriétés ajoutées sans migration
  • Relations profondes : navigation récursive native (:amis+)
  • Inférence : RDFS, OWL, règles personnalisées
  • Données hétérogènes : fusion de sources avec mapping sémantique
  • Web sémantique : interopérabilité avec RDF, JSON-LD
  • Linked Data : interroger des données distribuées sur le web
  • Recherche sémantique : comprendre l'intention plutôt que la syntaxe
📝 Requête SPARQL typique :
# Tous les produits qui sont des "chaussures" ou leurs sous-catégories
SELECT ?produit WHERE {
    ?produit rdf:type/rdfs:subClassOf* :Chaussure .
}
05

📊 Quand utiliser SQL ?

✅ SQL excelle pour :

  • Données tabulaires : lignes et colonnes clairement définies
  • Transactions ACID : bancaire, e-commerce, inventaire
  • Agrégations massives : SUM, COUNT, AVG sur millions de lignes
  • Reporting et BI : Tableau, PowerBI, Metabase
  • Schéma stable : données structurées, peu d'évolutions
  • Écosystème mature : ORM (Hibernate, Entity Framework), outils
  • Compétences disponibles : SQL est enseigné partout
📝 Requête SQL typique :
# Chiffre d'affaires par mois
SELECT 
    DATE_TRUNC('month', date_commande) as mois,
    SUM(montant) as ca,
    COUNT(*) as nb_commandes
FROM commandes
GROUP BY DATE_TRUNC('month', date_commande)
ORDER BY mois DESC;
06

⚡ Performance comparée

Type de requêteSQLSPARQL
JOIN 2 tables / pattern simple✅ Excellente✅ Très bonne
JOIN 5+ tables / pattern complexe⚠️ Dégradation✅ Stable
Relations récursives (profondeur 5+)❌ Complexe, lent✅ Native, rapide
Agrégations massives (SUM, COUNT)✅ Excellente⚠️ Plus lent
Inférence / raisonnement❌ Non natif✅ Natif (avec raisonneur)
Insertion en masse✅ Excellente⚠️ Variable
💡 Benchmark indicatif :
  • SQL peut interroger 100M+ lignes en <100ms pour des agrégations simples
  • SPARQL peut naviguer 10 niveaux de relations en <50ms là où SQL prendrait plusieurs secondes
  • Le choix dépend de votre pattern d'accès aux données
07

🏆 Verdict

SQL reste roi pour :

  • ✅ Transactions, reporting, BI, ERP, CRM
  • ✅ Données tabulaires avec schéma stable
  • ✅ Équipes déjà formées au SQL

SPARQL est supérieur pour :

  • ✅ Graphes de connaissances, données interconnectées
  • ✅ Navigation profonde dans les relations
  • ✅ Inférence et raisonnement sémantique
  • ✅ IA, RAG, recherche sémantique
  • ✅ Intégration de données hétérogènes

Recommandation :

Ne choisissez pas l'un ou l'autre par dogme. Utilisez SQL pour ce pour quoi SQL est bon (transactions, reporting) et SPARQL pour ce pour quoi SPARQL est bon (graphes, relations, inférence). Beaucoup d'entreprises utilisent les deux en synergie.

🚀 Apprenez SPARQL maintenant 📘 Guide SPARQL complet →