Comment est-il nécessaire ou pratique d'écrire du SQL portable?

Question

À maintes reprises, j'ai vu des gens ici et ailleurs préconiser l'évitement des extensions non-portables au langage SQL, this étant le dernier exemple. Je me souviens d'un seul article qui dit ce que je vais dire, et je n'ai plus ce lien.

Avez-vous réellement bénéficié de l'écriture de SQL portable et du rejet des outils/syntaxes propriétaires de votre dialecte?

Je n'ai jamais vu un cas de quelqu'un qui prend des douleurs pour construire une application complexe sur mysql et puis dire Vous savez ce qui serait juste Peachy? Passons à (PostGreSQL | Oracle | SQL Server)!

Les bibliothèques communes dans -say- PHP font abstraction des subtilités de SQL, mais à quel prix? Vous finissez par être incapable d'utiliser des constructions et des fonctions efficaces, pour une lueur présumée de portabilité que vous n'utiliserez probablement jamais. Cela me ressemble comme un manuel YAGNI.

EDIT: Peut-être l'exemple je l'ai mentionné est trop sarcastique, mais je pense que le point reste: si vous envisagez un déménagement d'un SGBD à l'autre, vous redessinent probablement l'application de toute façon, ou vous ne seriez pas le faire du tout.

Answer 1

Les fournisseurs de logiciels qui traitent avec les grandes entreprises peuvent ne pas avoir le choix (en fait c'est mon monde) - leurs clients peuvent avoir des politiques d'utilisation des produits d'un seul fournisseur de base de données. Passer à côté de grands clients est difficile sur le plan commercial.

Lorsque vous travaillez au sein de une entreprise, vous pouvez être en mesure de bénéficier de la connaissance de la plate-forme. En règle générale, la couche DB doit être bien encapsulée, donc même si vous deviez transférer vers une nouvelle base de données, la modification ne devrait pas être omniprésente. Je pense qu'il est raisonnable d'adopter une approche de portage YAGNI à moins d'avoir une demande spécifique pour un support immédiat multi-fournisseurs. Faites-le fonctionner avec votre base de données cible actuelle, mais structurez le code avec soin pour permettre la portabilité future.

Answer 2

Dans la grande majorité des applications, je parierais qu'il y a peu ou pas d'avantages et même un effet négatif d'essayer d'écrire portable SQL; Cependant, dans certains cas, il existe un cas d'utilisation réel. Supposons que vous construisez une application Web de suivi du temps. Et vous souhaitez proposer une solution auto-hébergée.

Dans ce cas, vos clients auront besoin d'un serveur DB. Vous avez quelques options ici. Vous pourriez les forcer à utiliser une version spécifique qui pourrait limiter votre base de clients. Si vous pouvez prendre en charge plusieurs SGBD, vous avez un client potentiel plus large qui peut utiliser votre application Web.

Answer 3

• Si vous êtes d'entreprise, vous utilisez la plate-forme vous donne
• Si vous êtes un vendeur, vous devez planifier pour plusieurs plates-formes

longevite de l'entreprise:

• Vous allez probablement réécrire le code client avant de migrer le SGBD
• Le SGBD va probablement survivre à votre code client (Java ou C# contre '80 mainfra moi)

Rappelez-vous:

SQL au sein d'une plate-forme est généralement rétrocompatible, mais les bibliothèques clientes ne sont pas. Vous êtes obligé de migrer si le système d'exploitation ne peut pas prendre en charge une ancienne bibliothèque, un environnement de sécurité, une architecture de pilote ou une bibliothèque 16 bits.

Par conséquent, supposons que vous disposiez d'une application sur SQL Server 6.5. Il fonctionne encore avec quelques réglages sur SQL Server 2008. Je parie que vous n'utilisez pas le code client sain ...

Answer 4

Le problème avec les extensions est que vous devez les mettre à jour lorsque vous mettez à jour le système de base de données lui-même . Les développeurs pensent souvent que leur code durera pour toujours mais la plupart du code devra être réécrit d'ici 5 à 10 ans. Les bases de données ont tendance à survivre plus longtemps que la plupart des applications, car les administrateurs sont assez intelligents pour ne pas réparer les éléments qui ne sont pas endommagés, de sorte qu'ils ne mettent souvent pas à niveau leurs systèmes avec chaque nouvelle version.
Encore, c'est une vraie peine lorsque vous mettez à jour votre base de données vers une version plus récente, mais les extensions ne sont pas compatibles avec celle-ci et ne fonctionneront donc pas. Cela rend la mise à niveau beaucoup plus complexe et demande plus de code à réécrire.
Lorsque vous choisissez un système de base de données, vous êtes souvent bloqué avec cette décision pendant des années.
Lorsque vous choisissez une base de données et quelques extensions, vous êtes bloqué avec cette décision pour beaucoup, beaucoup plus longtemps!

Answer 5

Le seul cas où je peux le voir nécessaire est lorsque vous créez un logiciel que le client achètera et utilisera sur ses propres systèmes. De loin, la majorité de la programmation ne tombe pas dans cette catégorie. Refuser d'utiliser le code spécifique au fournisseur, c'est s'assurer que vous avez une base de données performante car le code spécifique au vendeur est généralement écrit pour améliorer la performance de certaines tâches sur SQL standard ANSII et écrit pour bénéficier de l'architecture spécifique de cette base de données. Je travaille avec des bases de données depuis plus de 30 ans et je n'ai jamais vu une entreprise changer sa base de données backend sans une réécriture complète de l'application. Éviter le code spécifique au fournisseur dans ce cas signifie que vous nuire à vos performances sans raison la plupart du temps.

J'ai également utilisé beaucoup de produits commerciaux différents avec des bases de données au fil des ans. Sans exception, chacun d'entre eux a été écrit pour soutenir plusieurs backends et, sans exception, chacun d'entre eux était un chien misérable, lent d'un programme à utiliser quotidiennement.

Answer 6

Il y a toujours des avantages et des coûts à utiliser le dialecte du «plus petit dénominateur commun» d'une langue afin de sauvegarder la portabilité. Je pense que les dangers d'un verrouillage sur un SGBD particulier sont faibles, comparés aux dangers similaires pour la programmation des langages, des bibliothèques d'objets et de fonctions, des rédacteurs de rapports, et autres.

Voici ce que je recommanderais comme moyen principal de protéger la portabilité future. Créez un modèle logique du schéma qui inclut des tables, des colonnes, des contraintes et des domaines. Faites en sorte que le SGBD soit indépendant de ce que vous pouvez, dans le contexte des bases de données SQL.La seule chose qui dépendra du dialecte est le type de données et la taille de quelques domaines. Certains dialectes plus anciens n'ont pas de support de domaine, mais vous devriez quand même faire votre modèle logique en termes de domaines. Le fait que deux colonnes soient tirées du même domaine et ne partagent pas seulement un type de données et une taille communs est d'une importance cruciale dans la modélisation logique.

Si vous ne comprenez pas la distinction entre la modélisation logique et la modélisation physique, apprenez-la.

Faites autant de la structure d'index portable que vous le pouvez. Bien que chaque SGBD possède ses propres caractéristiques d'index spéciales, la relation entre les index, les tables et les colonnes dépend de l'indépendance du SGBD.

En termes de traitement SQL CRUD au sein de l'application, utilisez des constructions spécifiques au SGBD chaque fois que nécessaire, mais essayez de les conserver documentées. A titre d'exemple, je n'hésite pas à utiliser la construction "CONNECT BY" d'Oracle chaque fois que je pense que cela me fera du bien. Si votre modélisation logique a été indépendante du SGBD, une grande partie de votre SQL CRUD sera également indépendante du SGBD même sans trop d'efforts de votre part.

Quand vient le temps de bouger, attendez-vous à des obstacles, mais attendez-vous à les surmonter de façon systématique.

(Le mot « vous » dans ce qui précède est à qui cela peut concerner, et non à l'OP en particulier.)