Meilleures pratiques pour maximiser la portabilité dans SQL Server 2016
Quand il s'agit de développer le prototype d'une solution, souvent les technologies n'ont pas encore été décidées et peuvent ne pas être les mêmes que celles qui seront utilisées dans le produit fini.
Dans ces scénarios, j'ai tendance à utiliser Microsoft SQL Server pour écrire les requêtes aussi standard que possible pour simplifier la migration éventuelle vers un autre serveur.
Existe-t-il un moyen ou une pratique connue d'imposer l'utilisation du dialecte SQL standard sur T-SQL directement dans SQL Server ou via SQL Server Management Studio (SSMS)?
L'utilisateur Aaron Bertrand a fait quelques commentaires qui correspondent bien à mes réflexions sur votre question. Il s'agit plus d'un défi de cadre que d'une réponse à votre question spécifique, mais je pense qu'il est utile de considérer dans ce contexte.
La portabilité est un objectif de Nice, mais cela arrive rarement dans la pratique.
Si vous devez changer de plate-forme à un moment donné, il y aura changements nécessaires à l'application, à la base de données et probablement beaucoup d'autres choses. Si vous pouvez être quelque peu "agnostique à la plate-forme" sans trop d'effort, c'est bien. Mais c'est vraiment une mauvaise décision commerciale de l'utiliser comme objectif de conception.
Il existe de nombreux endroits en ligne où les gens discutent des inconvénients ou de la programmation de cette façon, voici l'un d'entre eux que je trouve assez convaincant:
Les couches d'abstraction de base de données doivent mourir!
Le sophisme de la portabilité
L'auteur utilise un argument que j'entends tout le temps: si vous utilisez une bonne couche d'abstraction, il sera facile de passer de $ this_database à $ other_database sur la route.
C'est n'importe quoi. Ce n'est jamais facile.
Dans toute application non triviale soutenue par une base de données, personne ne pense à changer de base de données comme une question facile. Penser que "la conversion sera indolore" est un fantasme.
Les bons ingénieurs essaient de sélectionner les meilleurs outils pour le travail, puis font tout ce qu'ils peuvent pour tirer parti des fonctionnalités uniques et les plus puissantes de leur outil. Dans le monde des bases de données, cela signifie des conseils spécifiques, une indexation, des types de données et même des décisions de structure de table. Si vous vous limitez vraiment au sous-ensemble de fonctionnalités qui est commun à tous les principaux SGBDR, vous faites vous-même et vos clients un énorme mauvais service.
Ce n'est pas différent de dire "je fais pour me limiter au sous-ensemble de PHP c'est la même chose en Perl et C, parce que je pourrais vouloir changer de langue un jour et porter 'indolore' mon code."
Cela n'arrive tout simplement pas.
Le coût de changement de base de données après le développement et le déploiement d'une application est assez élevé. Vous avez des modifications de schéma et d'index possibles, des changements de syntaxe, des travaux d'optimisation et de réglage à refaire, des conseils pour ajuster ou supprimer, etc. Changer mysql_foo () en Oracle_foo () est vraiment le moindre de vos problèmes. Vous allez toucher la plupart, sinon la totalité, de votre SQL - ou vous devrez au moins le vérifier.
Cela ne me semble pas "indolore".
N'appliquez pas STD SQL.
Décidez d'abord quel SGBD vous utiliserez en fonction des besoins de votre projet et profitez-en.
Pas vraiment.
Il y a SET FIPS_FLAGGER 'FULL' .
Cela affiche un avertissement pour SQL non standard - mais certaines mises en garde sont
- Je ne sais pas quel standard spécifique cela utilise (et je soupçonne qu'il peut s'agir de SQL 92)
- D'un test rapide, cela ne se plaint pas de l'utilisation de l'opérateur
+Pour la concaténation de chaînes ou de fonctions propriétaires telles queGETDATE()donc cela ne semble pas très complet.
"souvent les technologies n'ont pas encore été décidées"
Je dirais que ce n'est absolument pas le cas dans mon expérience. En fait, je ne pense pas en avoir entendu parler, sauf peut-être quelque chose de très petit.
Habituellement, cela est établi et la nouvelle solution devrait utiliser ce qui est déjà utilisé.
Je serais d'accord avec les commentateurs ci-dessus en ce que même si ce n'est pas établi, vous devez d'abord l'établir avant de commencer à écrire des requêtes et d'autres codes. Sinon, vous vous laissez potentiellement potentiellement dépenser beaucoup d'efforts en une réécriture dès le départ.