Unifier SQL et NoSQL sans les abstraire artificiellement

Unification ≠ Abstraction

QoreDB ne cherche pas à faire croire que SQL et NoSQL sont des variantes d’un même modèle.
Ils ne le sont pas.

L’objectif n’est pas de lisser leurs différences, mais de permettre de les manipuler dans un même outil sans perte de sens, de puissance ou de contrôle.

Cette approche peut se résumer ainsi :

standardiser la structure, préserver la sémantique.

Une approche volontairement opposée aux ORM

Les ORM (Prisma, TypeORM, Hibernate) et certaines couches d’abstraction (ODBC, JDBC) tentent de masquer les différences entre moteurs.

Ils introduisent :

• un langage intermédiaire,
• un modèle commun appauvri,
• des limitations structurelles liées à ce qu’ils savent interpréter.

QoreDB adopte l’approche inverse.

Il n’essaie jamais de traduire votre intention.
Il vous fournit un canal direct vers le moteur de la base.

1. Lifecycle unifié, exécution native

Le cœur du backend repose sur un trait commun : DataEngine.

Ce trait standardise uniquement le cycle de vie, pas le langage.

Ce qui est unifié (le contenant)

Les opérations suivantes sont communes à tous les moteurs :

• connexion
• listing des namespaces (bases)
• listing des collections ou tables

Cela permet à l’interface d’afficher :

• un arbre de navigation cohérent,
• une organisation stable, quel que soit le moteur.

Ce qui reste natif (le contenu)

La méthode centrale est volontairement simple :

QoreDB ne transforme jamais la requête.

• PostgreSQL : SQL pur (SELECT, CTE, window functions)
• MongoDB : JSON pur (find, aggregate, pipelines complexes)

La requête est transmise telle quelle au driver natif.

2. Deux éditeurs, deux langages, zéro traduction

Cette décision est visible côté interface.

Le frontend ne propose pas un éditeur générique.
Il expose explicitement deux environnements distincts :

• un éditeur SQL dédié
• un éditeur MongoDB basé sur JSON

Aucun mécanisme ne tente de convertir :

• du SQL en MongoDB,
• du MongoDB en SQL.

L’intention du développeur n’est jamais interprétée.
Elle est respectée.

3. Un système de types hybride, pas un dénominateur commun

QoreDB ne force pas le NoSQL dans une table relationnelle.
Il ne force pas non plus le SQL dans du JSON arbitraire.

Le système de types reflète cette réalité.

Une valeur peut être :

• strictement typée (entiers, texte),
• un document JSON riche,
• une structure imbriquée.

Conséquences directes :

• une requête MongoDB retourne un document JSON complet,
• une requête SQL retourne des colonnes typées,
• aucune conversion forcée vers un modèle universel appauvri.

La donnée conserve sa structure et sa sémantique d’origine.

4. Absence totale de “query layer” magique

Il n’existe dans QoreDB :

• ni AST intermédiaire,
• ni query builder générique,
• ni langage propriétaire.

Cela implique :

• accès à 100 % des fonctionnalités natives du moteur,
• aucune limitation imposée par l’outil,
• aucun décalage entre ce que la base sait faire et ce que l’outil autorise.

Un ORM vous limite à ce qu’il comprend.
QoreDB vous laisse parler directement à la base.

Conclusion

QoreDB unifie l’expérience, pas les modèles.

Il fournit :

• un point d’entrée commun,
• une navigation cohérente,
• une visualisation homogène.

Mais il refuse :

• de traduire les requêtes,
• d’aplatir les données,
• d’inventer un langage intermédiaire.

QoreDB n’est pas un traducteur.
C’est un hub.

Un outil qui respecte la diversité des moteurs
au lieu de la masquer artificiellement.