Discussion :

[hmira]

Bonjour,

Y-aurait-il selon vous des inconvénients ou des contres indications à ce que l'environnement de développement soit sous SQL Server 2014, c.à.d. poste des développeurs SSMS etc. sous SQL Server 2014, ainsi que les instances SQL Server dédiées au développement soient sous SQL Server 2014, alors que les environnements de recette (qualification des applications etc.) ainsi que les environnements de production sont actuellement sous SQL Server 2008 R2.

Ou au contraire cela ne poserait aucun problème (?).

Sachant qu'il a été prévu à minima, pour éviter d'éventuels soucis, que les bases de données de développement sous SQL Server 2014, soient en mode de compatibilité 2008 (Compatibility Level = 100)

PS : Personnellement je n'aurais ni fait, ni envisagé de choix, mais je ne décide pas de tout !
J'aurais faits en sorte que l'environnement de développement soit cohérent avec les environnements de qualifications et de productions, c.à.d. sous SQL Server 2008 R2 et ce, jusqu'à nouvel ordre, c.à.d. jusqu’à décider dans un avenir futur de hisser l'ensemble des environnements vers SQL Server 2014. Mais peut-être que l’impact est minime et que je prends trop de précautions (?).

Merci pour vos conseils avisés.

A+

[aieeeuuuuu]

Bonjour,

Oui, je vois bien quelques petits problèmes, la vraie question serait plutôt : quel est l’intérêt ?


jouer sur le mode de compatibilité n'est pas suffisant.
Un exemple, qui me passe par la tête pour illustrer

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
 
BEGIN TRY
 ...
END TRY
BEGIN CATCH
 THROW;
END CATCH

Passera sous un 2014 en compatibilité 2008, mais échouera sur un 2008.

Vous risquez donc d'avoir des surprises au moment de l'installation sur les serveurs de recette, voire même plus tard (si le code SQL est en exécution dynamique par exemple).

[hmira]

Merci beaucoup aieeeuuuuu pour tes remarques ainsi que les exemples concrets et très intéressant que tu as soulignés.

L'intérêt ou arguments qui ont motivés ce choix sont, d'après ce que j'ai pu comprendre, plutôt d'ordre "marketing", du style , nous sommes partenaire Microsoft et nous utilisons les dernières technologies etc (SQL server 2014, etc.) pour le développements des produits et rassurer ainsi les clients qui auraient opté pour SQL Server 20012 ou SQL Server 2014 pour leurs parc. Arguments qu'on peut comprendre.

En tout cas, la recette et la qualification des applications sera effectuée intensivement en environnement SQL Server 2008 R2, ce qui représente l'environnement de la quasi totalité des clients. J'ai appris que la qualification est également effectuée, à moindre effort, en environnement SQL 2012 et SQL 2014.

Voilà ta réponse me conforte dans mon analyse. Personnellement j'étais comme toi très réticent sur ce choix

J'ai toutefois demandé et insisté sur le fait d'avoir deux environnements de développement SQL Server 2O08 R2 en plus de SQL Server 20014 déjà prévu, et "exigé" à ce que les développeurs testent également et impérativement en environnement SQL 2008 R2 avant de livrer leur production.

Merci,

A+

[julien94320]

Bonjour,

A mon sens le choix n'est pas judicieux pour les motifs suivants :

Des fonctionnalités existent dans la version 2014 qui n'existent pas dans la version 2008 R2

Comment expliquer aux developpeurs qu'ils n'ont pas le droit d'utiliser :

• Le Columnstore Index
• Le In Memory
• le LEAD / LAG
• L'apparation du SSIS catalog qui n'existe pas en 2008R2
• ...

Et bien d'autres fonctionnalités qui sont apparu à partir de la version 2012 et qui ne sont pas disponibles sur la version 2008R2 ...

Devront ils reprendrent leur dev si ils utilisent ces fonctionnalités disponible en 2014 ?

Autre point "problématique", le comportement du moteur : Certains correctifs en 2014 changent le comportement du moteur, l'analyse des plans peut complément changer entre les environements et tromper le developpeur ....

Et je ne parle pas de la politique de licence chez MS en cas de controle ça peut etre sport !

Bref pour moi cette architecture peut etre envisagé temporairement le temps d'une migration mais, ne peut pas etre pérénisé ...

A+

Julien

[Invité]

Comment expliquer aux developpeurs qu'ils n'ont pas le droit d'utiliser :

• Le Columnstore Index
• Le In Memory
• le LEAD / LAG
• L'apparation du SSIS catalog qui n'existe pas en 2008R2
• ...

Il existe vraiment des développeurs qui connaissent ça ?
J'explique les jointures externes et c'est déjà pas évident alors, les indexes, c'est pour l'année prochaine...

[julien94320]

Il existe vraiment des développeurs qui connaissent ça ?
J'explique les jointures externes et c'est déjà pas évident alors, les indexes, c'est pour l'année prochaine...

Et oui ça arrive et même que parfois ils l'utilisent !

Je viens de former des dev aux nouveautés SQL 2016 ... Et ils vont l'utiliser sur leurs nouveaux projets ... Et puis dans la doc en cherchant un peu parfois on tombe sur une fonctionnalité super, on test pouf ça marche ! Mais c'est une fonctionnalitée de la nouvelle version !

[hmira]

Merci beaucoup Julien pour ton analyse bien étayée que je personnellement je partage parfaitement, excepté ton allusion à la politique de licence chez MS.
Il n'a y aucun problème de licence. La société est partenaire Microsoft et dispose de licences parfaitement légales de toutes les versions SQL Server.

Le choix de SQL Server 2014 pour l'environnement de développement est une décision presque arbitraire qui malheureusement ne tient pas compte des considérations et problématiques soulevés par certains d'entre nous.

Bref, je vous remercie à tous de vos réponses. Je vais donc clôturer cette discussion avec la conclusion confirmée que le choix "Env. de Dev. SQL 2014 pour un Env. de Prod SQL 2008 R2" n'est pas une sage décision et présente plus de problèmes qu'il revêt d'intérêts si tenté que l'on puisse parler d'un intérêt quelconque pour ce choix !

A+

[julien94320]

Merci beaucoup Julien pour ton analyse bien étayée que je personnellement je partage parfaitement excepté ton allusion à la politique de licence chez MS.

Pour la politique de licence je dis ça car parfois, Microsoft peut etre "tatillons" en terme de support, si tous les environnements ne sont pas ISO ... Sans parlé d'une facturation différente. Mais c'est un autre débat

Content que ma réponse t'es sastisfait.