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

Question

À maintes reprises, j'ai vu des gens, ici et partout ailleurs, préconiser d'éviter les extensions non portables du langage SQL, ceci étant le dernier exemple. Je ne me souviens que d’un article indiquant ce que je vais dire et je n’ai plus ce lien.

Avez-vous réellement profité de l’écriture de code SQL portable et de l’abandon des outils / syntaxes propriétaires de votre dialecte?

Je n'ai jamais vu un cas où quelqu'un se donnerait la peine de créer une application complexe sur mysql, puis de se dire Vous savez ce qui ne serait que pêche? Passons à (PostGreSQL | Oracle | SQL Server)!

Les bibliothèques courantes dans -say-PHP font la synthèse 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 semble être le manuel YAGNI.

EDIT: L'exemple que j'ai cité est peut-être trop sournois, mais je pense que le problème demeure: si vous envisagez de passer d'un SGBD à un autre, vous modifiez probablement l'application de toute façon, ou vous ne le ferait pas du tout.

Answer 1

Les éditeurs de logiciels qui traitent avec de grandes entreprises n’ont peut-être pas le choix (c’est mon monde à moi). Leurs clients peuvent avoir pour politique d’utiliser uniquement les produits d’un fournisseur de base de données. Rater des clients importants est une tâche difficile sur le plan commercial.

Lorsque vous travaillez au sein d'une entreprise, vous pouvez bénéficier des connaissances de la plate-forme.

En règle générale, la couche de base de données doit être bien encapsulée. Par conséquent, même si vous deviez effectuer un transfert vers une nouvelle base de données, la modification ne devrait pas être généralisée. Je pense qu’il est raisonnable d’adopter une approche YAGNI en matière de portage, sauf si vous avez une exigence spécifique en matière de support multi-fournisseurs immédiat. Faites-le fonctionner avec votre base de données cible actuelle, mais structurez le code avec précaution pour permettre la portabilité future.

Answer 2

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 éternellement, mais la plupart du code devra être réécrit dans 5 à 10 ans. Les bases de données ont tendance à survivre plus longtemps que la plupart des applications, car les administrateurs sont suffisamment intelligents pour ne pas réparer les choses qui ne sont pas en panne, de sorte qu'ils ne mettent souvent pas à niveau leurs systèmes avec chaque nouvelle version.
Pourtant, la mise à niveau de votre base de données est pénible. 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 pris avec cette décision pendant des années.
Lorsque vous choisissez une base de données et quelques extensions, vous êtes coincé avec cette décision pour beaucoup, beaucoup plus longtemps!

Answer 3

Le seul cas où je vois que cela est nécessaire est lorsque vous créez un logiciel que le client achètera et utilisera sur ses propres systèmes. La grande majorité de la programmation ne rentre pas dans cette catégorie. Refuser d'utiliser du code spécifique au fournisseur, c'est s'assurer que vous disposez d'une base de données extrêmement performante, car le code spécifique au fournisseur est généralement écrit pour améliorer les performances de certaines tâches par rapport à ANSII Standard SQL et écrit pour tirer parti 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 encore jamais vu une société modifier sa base de données back-end sans une réécriture complète de l’application. Dans ce cas, éviter le code spécifique au fournisseur signifie que vous nuisez à vos performances sans aucune raison que ce soit la plupart du temps.

J'ai également utilisé de nombreux produits commerciaux avec des bases de données au fil des ans. Sans exception, chacun d’entre eux a été écrit pour prendre en charge plusieurs serveurs et, sans exception, chacun d’entre eux était un chien lamentable et lent d’un programme à utiliser réellement au quotidien.

Answer 4

Dans la grande majorité des applications, je parierais qu’il ya peu ou pas d’avantages et même un effet négatif d’essayer d’écrire en SQL portable; 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 devront disposer d’un serveur de base de données. Vous avez quelques options ici. Vous pouvez les forcer à utiliser une version spécifique qui pourrait limiter votre base de clients. Si vous pouvez prendre en charge plusieurs SGBD, vous disposez d'un client potentiel plus étendu pouvant utiliser votre application Web.

Answer 5

• Si vous êtes une entreprise, vous utilisez la plate-forme qui vous a été attribuée
• Si vous êtes un fournisseur, vous devez planifier plusieurs plates-formes

Longévité pour les entreprises:

• Vous allez probablement réécrire le code client avant de migrer le SGBD
• Le SGBD survivra probablement à votre code client (Java ou c # par rapport à l'ordinateur central '80)

N'oubliez pas:

SQL au sein d’une plate-forme est généralement compatible avec les versions antérieures, mais pas les bibliothèques clientes. 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, une bibliothèque 16 bits, etc.

Supposons donc que vous aviez une application sur SQL Server 6.5. Il fonctionne toujours avec quelques modifications sur SQL Server 2008. Je parie que vous n'utilisez pas le code client sensé ...

Answer 6

L’utilisation du "plus petit dénominateur commun" présente toujours des avantages et des coûts. dialecte d’une langue afin de préserver la portabilité. Je pense que les dangers du verrouillage sur un SGBD particulier sont faibles, comparés aux dangers similaires rencontrés pour la programmation de languges, de bibliothèques d'objets et de fonctions, d'écriveurs de rapports, etc.

Voici ce que je recommanderais comme moyen principal de préserver la portabilité future. Créez un modèle logique du schéma comprenant des tables, des colonnes, des contraintes et des domaines. Rendez-le aussi indépendant que possible du SGBD, 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 manquent de prise en charge de domaine, mais vous devriez quand même créer votre modèle logique en termes de domaines. Le fait que deux colonnes soient tirées du même domaine et ne partagent pas simplement un type de données et une taille communs est d’une importance cruciale pour la modélisation logique.

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

Faites en sorte que la structure de l’index soit aussi portable que possible. Bien que chaque SGBD possède ses propres fonctionnalités d'index spéciales, la relation entre les index, les tables et les colonnes est à peu près indépendante du SGBD.

En termes de traitement CRUD SQL au sein de l’application, utilisez des constructions spécifiques au SGBD chaque fois que nécessaire, mais essayez de les conserver documentées. Par exemple, je n'hésite pas à utiliser le logiciel "CONNECT BY" d'Oracle. construire à 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 code CRUD SQL le sera également, même sans trop d'effort de votre part.

Le moment venu, attendez-vous à certains obstacles, mais attendez-vous à les surmonter de manière systématique.

(Le mot "vous" dans ce qui précède est destiné à qui de droit, et pas au PO en particulier.)