Quelle est la compatibilité des moteurs de base de données au niveau SQL?

Question

Supposons que je souhaite disposer d’une application capable de basculer facilement la base de données en back-end.
Je pense principalement à SQL Server en tant que back-end principal, mais avec la possibilité d'utiliser un autre moteur de base de données. Firebird et PostGreSQL semblent avoir (d'après ma brève excursion sur Wikipédia) le plus commun avec SQL Server (en plus, ils sont gratuits).

Dans quelle mesure la configuration, les accès, les requêtes, etc. de la base de données seraient-ils similaires pour Firebird, PostGreSQL et MS SQL Server?

Answer 1

J'ai travaillé sur un projet où la prise en charge de nombreuses bases de données, dont au moins Access, SQL Server et Oracle, était une nécessité absolue.

Je sais donc que cela peut être fait. La plupart du temps, le format DML (SELECT, UPDATE, INSERT ...) est identique et nous n’avons certainement pas eu d’énormes problèmes pour le faire fonctionner sur toutes les bases de données - juste des ennuis occasionnels. MySQL était l'exception à cette époque car il n'était tout simplement pas assez capable.

Nous avons trouvé la plupart des différences dans le DDL, mais avec la bonne architecture (que nous avions), il n’était pas difficile de résoudre ce problème.

La seule chose qui nous a causé un problème a été la génération d'identifiants uniques - l'auto-incrémentation n'est pas standard. Dans une base de données d'environ 40 tables, il n'y avait que quelques endroits où des identifiants uniques étaient nécessaires (bonne conception de base de données). Au final, nous générons l’identifiant unique dans le code et gérons les conflits éventuels (tout dans les transactions).

Cela nous a facilité la tâche, car nous avions évité d'utiliser l'auto-incrémentation pour les champs ID. Il est plus difficile de penser à des clés uniques, mais mieux à long terme.

Answer 2

Malheureusement, SQL varie considérablement d'un fournisseur à l'autre. Il est presque impossible d'écrire tout le code SQL, sauf le plus trivial, sur un certain nombre de SGBDR - et vous vous retrouvez alors dans le plus petit territoire de dénominateur commun. Il est de loin préférable d’utiliser une couche d’abstraction pour gérer au moins la connexion à la base de données (accès, envoi de requêtes compris) et un ORM pour gérer le code SQL lui-même ou le code SQL par fournisseur.

Si vous voulez voir comment ils varient, de bons exemples sont les identifiants à incrémentation automatique et l'obtention de l'ID du dernier enregistrement inséré.

Answer 3

Eh bien, le contenu de CRUD devrait être identique partout, mais si vous construisez quelque chose de complexe, vous voudrez probablement utiliser des déclencheurs et des procédures stockées et c’est là que la compatibilité devient faible. Écrire une application indépendante du SGBD implique généralement de déplacer la plupart de la logique métier en dehors de la base de données. Il est donc essentiel d'avoir une application à 3 niveaux, à mon humble avis, dans un tel cas.

Vous pouvez également utiliser une bibliothèque de wrapper qui fonctionne comme une couche d'abstraction, mais je ne vois pas encore de bibliothèque capable de faire le travail correctement sur une plage de SGBD. Bien sûr, cela dépend aussi du langage de programmation que vous utilisez.

Answer 4

Comme indiqué dans les autres réponses, les SGBD varient énormément lorsque vous allez au-delà des éléments de base de SELECT / INSERT (et parfois même de là).

Nous devons également maintenir la compatibilité entre plusieurs SGBD. À mon avis, la meilleure approche consiste généralement à utiliser un type de couche de compatibilité. Nous disposons d'une bibliothèque d'abstraction de base de données interne, mais plusieurs outils sont disponibles.

En particulier, il peut être intéressant de consulter les ORM populaires (Hibernate, nHibernate, etc.). Ils offrent généralement l’indépendance de la base de données comme une sorte d’effet secondaire. Au moins, Hibernate possède également un langage de requête spécial qui sera automatiquement traduit en SQL pour le SGBD que vous utilisez.