Meilleures pratiques pour maximiser la portabilité dans SQL Server 2016

8

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)?

— s.demuro
source

3

La portabilité est un bon objectif de manuel, mais cela arrive rarement dans la pratique. Lorsque vous avez le choix entre la syntaxe standard ( <>) et non standard ( !=), où il n'y a aucun compromis sur les performances ou la maintenabilité, je choisis toujours standard. Mais quand cela vient à d'autres coûts, ou qu'il n'y a pas d'équivalent standard, je tape et je suis propriétaire. Les choses que vous abandonnez juste pour la possibilité de changer complètement de plate-forme en gros ne valent tout simplement pas la peine à mon humble avis.

— Aaron Bertrand

6

Le seul moment où la portabilité est un objectif réaliste est lorsque vous écrivez une application qui doit s'intégrer à plusieurs plates-formes simultanément, car vos clients utilisent différentes plates-formes. Même dans ce cas, à moins que vous ne vouliez que les fonctionnalités soient limitées et les performances terribles sur toutes les plates-formes, j'expédierais des packages destinés à tirer parti des fonctionnalités des plates-formes individuelles.

— Aaron Bertrand

1

Juste curieux; dans l'histoire de tous les temps, avez-vous personnellement changé le système de base de données qu'une application utilisait pour une autre de qualité équivalente (par exemple Oracle -> SQLS)? Je n'ai pas

— Caius Jard

2

L'autre chose qui m'intéressait; Quelle proportion de votre prototype survit raisonnablement pour être un système de production complet? La plupart de mes prototypes ne partagent presque aucun aspect avec les systèmes complets qui y sont écrits une fois que le proto a prouvé un concept et a défini des approches sensées à quoi devrait ressembler une solution; rendez-vous vos prototypes trop parfaits / vous y accrochez-vous trop longtemps?

— Caius Jard

16

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 bon objectif de manuel, mais cela arrive rarement dans la pratique.

Si vous devez changer de plate-forme à un moment donné, des modifications devront être apportées à l'application, à la base de données et probablement à bien 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'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 qui est le même en Perl et C, parce que je pourrais vouloir changer de langue un jour et porter" sans douleur "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".

— Josh Darnell
source

11

N'appliquez pas STD SQL.

Décidez d'abord quel SGBD vous utiliserez en fonction des besoins de votre projet, et profitez-en.

— McNets
source

9

Pas vraiment.

Il y en a SET FIPS_FLAGGER 'FULL'.

Cela affiche un avertissement pour SQL non standard - mais certaines mises en garde sont

Je ne sais pas quelle norme 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 que GETDATE()cela ne semble pas très complet.

— Martin Smith
source

3

"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.

— Marbry Hardin
source