MySQL et PostgreSQL comme options backend natives

Le choix de la base de données fait partie de l’architecture du déploiement

Dans un système d’entreprise, la base de données ne dépend pas uniquement des préférences de l’équipe de développement. L’organisation peut appliquer des normes d’exploitation, disposer de ses propres administrateurs, avoir des procédures de sauvegarde existantes, suivre les exigences d’un fournisseur cloud ou subir les contraintes d’un hébergement géré. Sapphire I.C.D.S. prend donc en charge deux options backend natives, MySQL et PostgreSQL, sans imposer à toutes les installations un seul système prédéfini.

Le Roadmap public présente la prise en charge de PostgreSQL comme une amélioration publiée, accompagnée d’un choix complet entre les deux systèmes. Sur le plan architectural, cela va au-delà d’un second pilote : les requêtes, schémas des modules et règles d’exécution doivent exister pour les deux dialectes et conserver un comportement comparable.

Un contrat commun au-dessus de deux pilotes

Les niveaux supérieurs de Sapphire I.C.D.S. ne doivent pas dépendre directement de la bibliothèque cliente d’une base précise. Le contrôleur de données lit dans la configuration le type de backend retenu et obtient le pilote natif correspondant. Le module appelant conserve le même ensemble d’opérations : sélectionner des lignes, modifier des données, obtenir une valeur scalaire, insérer des lots, gérer des transactions et intervenir sur le schéma.

Cette séparation maintient le choix technologique dans la couche d’infrastructure. Un module d’articles ou de localisation formule une demande de domaine et exploite un résultat structuré, sans décider comment se connecter à MySQL ou PostgreSQL. Les différences entre les systèmes ne sont pas masquées par une abstraction illusoire : elles sont traitées par le pilote et le dialecte SQL appropriés.

Des modèles SQL distincts plutôt que des chaînes conditionnelles

Sapphire I.C.D.S. maintient les requêtes ordinaires séparément du module métier et les répartit par dialecte. Une même opération peut disposer de modèles MySQL et PostgreSQL partageant la même finalité et la même forme de résultat attendue. Avant l’exécution, le pilote actif sélectionne la variante adaptée, applique la couche de paramètres native et renvoie les données dans un conteneur tabulaire commun.

Cette portabilité est plus honnête que de déclarer tout le SQL universel. MySQL et PostgreSQL diffèrent par la syntaxe, les types, le traitement des identifiants, le renvoi des valeurs créées et certains détails d’expression. Des modèles distincts et vérifiables permettent de traiter explicitement ces différences sans multiplier les branches dans le module métier.

Ce qui reste identique pour les modules

• L’opération de domaine. Demander une liste, enregistrer une entrée ou effectuer une modification transactionnelle conserve une finalité métier unique.
• Les données d’entrée. Le module transmet des paramètres structurés dans l’environnement commun.
• La forme du résultat. Le consommateur reçoit un tableau ou une valeur avec des champs convenus.
• La limite transactionnelle. Les opérations qui doivent aboutir intégralement utilisent le contrat de transaction commun.
• Le choix du backend. Il relève de la configuration et du contrôleur, et non de conditions dispersées dans les modules.

Ce que le choix du backend n’automatise pas

La présence de deux options natives ne signifie pas qu’une base de production active puisse être remplacée par un simple réglage. La migration exige le transfert des schémas et des données, le contrôle des séquences et identifiants, la comparaison des types ainsi que la vérification des encodages, index et comportements transactionnels. Il faut une sauvegarde, un plan d’arrêt ou de synchronisation, une répétition et des critères de retour arrière.

La plateforme ne revendique pas non plus une réplication automatique entre MySQL et PostgreSQL, un failover intégré entre systèmes ou un cluster unique mêlant deux bases différentes. Ces sujets relèvent de l’infrastructure et doivent être conçus séparément. Le choix natif signifie que Sapphire I.C.D.S. sait fonctionner avec chaque option dans un déploiement pris en charge, et non que les deux systèmes sont interchangeables à tout moment sans préparation.

Comment choisir entre MySQL et PostgreSQL

Une décision rationnelle commence par l’environnement du client. Si l’organisation exploite déjà MySQL, possède des sauvegardes normalisées et une équipe compétente, changer de système uniquement pour un nouveau projet peut être sans avantage. De même, PostgreSQL est naturel lorsqu’il constitue la norme d’entreprise, est disponible dans une infrastructure gérée et s’intègre à la supervision et à la restauration existantes.

Il faut comparer non seulement la performance d’une requête, mais tout le cycle de vie : disponibilité des spécialistes, mises à jour, coût du service, observabilité, politique d’extensions, procédures de restauration et exigences relatives aux données. Les requêtes particulières d’un module doivent être mesurées sur un volume représentatif. Un contrat commun n’annule pas les différences entre optimiseurs et index.

La parité exige une discipline de développement

Chaque évolution de schéma ou de requête doit apparaître dans les deux dialectes si le module annonce les deux backend. Vérifier la présence des modèles ne suffit pas : il faut une installation propre, la réapplication sûre des migrations, des tests de lecture et d’écriture et une comparaison des résultats. Une attention particulière est nécessaire lorsque les systèmes comptent différemment les lignes modifiées ou traitent autrement un résultat vide.

Cette discipline augmente l’effort de validation, mais rend la portabilité réelle. Si un nouveau module ne fonctionne qu’avec un backend, cette limite doit être déclarée au lieu d’être masquée par une affirmation générale. La direction technique dispose ainsi d’un critère clair : la même opération métier doit produire un résultat équivalent sur les deux options prises en charge.

Le résultat opérationnel

Pour le propriétaire, deux backend natifs permettent d’inscrire Sapphire I.C.D.S. dans l’infrastructure existante et d’éviter des changements de compétences inutiles. Pour les architectes, la couche commune empêche les modules de dépendre directement d’un pilote. Pour les développeurs, les dialectes SQL distincts rendent les écarts visibles et vérifiables.

La valeur principale n’est pas une déclaration de compatibilité avec deux bases, mais une limite claire des responsabilités. L’organisation choisit et exploite le backend, le contrôleur raccorde le pilote natif, le module exécute l’opération de domaine et les tests confirment la parité. Le choix technologique reste ouvert sans masquer le coût réel de la migration et de la maintenance.