Introduction

Le langage de programmation SQL Server est un langage de programmation SQL destiné au serveur de base de données SQL Server de Microsoft. Il a été initialement développer par Sybase, Microsoft et Ashton-Tate en 1989. D'où la raison qu'il existe de nombreuses similitudes syntaxiques avec la base de données Sybase de SAP. La base de données SQL Server est un base de données avec comme force la capacité de manipuler des requêtes complexes rapidement. En autre, elle analysera une requête, compilera la requête et optimisera la requête. On se retrouvera donc avec des meilleures performances plus on utilisera la base de données avec des requêtes similaires. La base de données SQL Server se distingue d'autres produits par le fait que d'une version à l'autre de la base de données, de nouvelles instructions, parfois peu utile, se rajoute continuellement. Ainsi, cette approche fait en sorte qu'il est souvent difficile d'utiliser une version plus ancienne de SQL Server à laquelle était destiné les données inséré dans la base de données plus récentes. Hélas, cette situation se produit lorsqu'un développeur veut importer une base de données de production avec une version SQL Server récente dans une base de données local avec une version SQL Server plus ancienne.

Remarques

• Deux groupes de rôle surpassent tous les autres droits et enlève carrément des accès partout respectivement en lecture et écriture : «db_denydatareader» et «db_denydatawriter». Il faut donc faire attention de ne pas sélectionner tous les groupes de rôles car vous n'aurez plus accès à rien.
• Azure : La base de données SQL Server est proposé en infonuagiques dans Azure de Microsoft sous le nom de Azure SQL Database, lequel est une version très proche du SQL Server mais gérer du côté d'Azure.
• Row Level Security : A partir de SQL Server 2016, le Row Level Security permet de répondre au besoin d'une sécurité accrue et d'améliorer la sécurité au niveau des lignes (RLS). Le RLS offre la possibilité de contrôler l'accès aux lignes d'une table en fonction de l'utilisateur exécutant une requête. Avec RLS, il est possible de mettre en oeuvre un mécanisme de filtrage sur n'importe quelle table d'une base de données de manière totalement transparente pour toute application externe ou accès direct à T-SQL. La possibilité de mettre en oeuvre un tel filtrage sans avoir à reconcevoir une couche d'accès aux données permet aux administrateurs système de contrôler l'accès aux données à un niveau encore plus granulaire qu'auparavant.
• Dynamic Data Masking : A partir du SQL Server 2016, le DDM, tirant son nom de l'anglicisme permet Dynamic Data Masking, à l'administrateur système de définir des algorithmes de masquage des données au niveau des colonnes empêchant les utilisateurs de lire le contenu sensible des colonnes, tout en pouvant interroger eux-mêmes les lignes. Cette fonctionnalité semble avoir été initialement destinée à permettre aux développeurs de travailler avec une copie des données de production sans avoir la possibilité de voir réellement les données sous-jacentes. Cela peut être particulièrement utile dans les environnements où les lois sur la protection des données sont appliquées (par exemple, les systèmes de traitement des cartes de crédit, l'entreposage des dossiers médicaux). Le masquage des données se produit pour les utilisateurs non autorisés lors de l'exécution de la requête et n'affecte pas les données entreposées d'une table. Cela signifie qu'il est possible de masquer une base de données de plusieurs téraoctets via une simple instruction DDL, plutôt que de recourir à la solution précédente consistant à masquer physiquement les données sous-jacentes dans la table que nous voulons masquer. La mise en oeuvre actuelle de DDM offre la possibilité de définir un ensemble fixe de fonctions sur les colonnes d'une table, ce qui masquera les données lorsqu'une table masquée est interrogée. Si un utilisateur est autorisé à afficher les données masquées, la ou les fonctions de masquage ne sont pas exécutées, tandis qu'un utilisateur sans ces autorisations recevra les données telles qu'elles sont vues à travers les fonctions de masquage définies.
• Always Encrypted : A partir de la version SQL Server 2016, le SQL Server propose le Always Encrypted. Le chiffrement avec SQL Server était auparavant une solution (principalement) basée sur un serveur. Les bases de données étaient soit protégées par un cryptage au niveau de la base de données (l'intégralité de la base de données était cryptée) soit au niveau de la colonne (les colonnes individuelles avaient un algorithme de cryptage défini). Alors que ce cryptage était et est entièrement fonctionnel et sûr, des parties cruciales du processus de cryptage (par exemple, les certificats de cryptage) sont entreposées dans SQL Server. Cela a effectivement donné au propriétaire d'une instance SQL Server la possibilité potentielle d'accéder à ces données chiffrées ; sinon directement, il y avait au moins une surface accrue pour une potentielle tentative d'accès malveillant. Alors que de plus en plus d'entreprises se sont tournées vers les services hébergés et les solutions infonuagiques (par exemple, Azure), les anciennes solutions de chiffrement n'offraient plus le niveau de contrôle et de sécurité requis. Le Always Encrypted a été conçu pour combler cette lacune de sécurité en supprimant la possibilité pour un propriétaire d'instance d'accéder aux composantes de chiffrement. L'intégralité du processus de chiffrement a été déplacée en dehors de SQL Server et réside du côté client. Auparavant, vous pouviez obtenir un effet similaire en utilisant une solution homebrew, mais Always Encrypted fournit une suite de cryptage entièrement intégrée à la fois dans la cadre d'application .NET et SQL Server. Chaque fois que les données sont définies comme nécessitant un cryptage, les données sont cryptées dans le cadre d'application .NET et envoyées à SQL Server uniquement une fois le cryptage effectué. Cela signifie qu'un utilisateur malveillant (ou même un administrateur système) ne pourra accéder aux informations cryptées que s'il tente d'interroger les données entreposées via Always Encrypted.
• Magazin des requêtes (Query Store) : Le Query Store est une fonctionnalité proposé à partir de SQL Server 2016. Les administrateurs de bases de données et les développeurs devraient être plus que familiarisés avec la situation d'une requête se comportant de manière fiable pendant une longue période, s'étant soudainement transformée en une requête lente. La requête de monstre tueur de ressources. Lors du dépannage des raisons pour lesquelles une requête immuable devient soudainement lente, il peut être très utile de connaître le ou les plans d'exécution de requête créés et utilisés par SQL Server. Un problème majeur lors de l'étude de ces types de problèmes est la nature transitoire des plans de requête et de leurs statistiques d'exécution. C'est là que Query Store entre en jeu ; le SQL Server collecte et entrepose en permanence des statistiques sur la compilation et l'exécution des requêtes par base de données. Ces informations sont ensuite conservées dans chaque base de données pour laquelle Query Store est activé, ce qui permet à un DBA ou à un développeur d'enquêter sur les problèmes de performances après coup. Il est même possible d'effectuer une analyse de régression des requêtes, ce qui donne un aperçu de l'évolution des plans d'exécution des requêtes sur une période plus longue. Ce type d'informations n'était auparavant possible que via des solutions écrites à la main ou des solutions de surveillance tierces, qui peuvent toujours ne pas permettre les mêmes informations que le Query Store.
• In-Memory OLTP : Le In-Memory OLTP (nom de code Hekaton) a été introduit dans SQL Server 2014. La promesse d'un traitement de données ultra-hautes performances dans SQL Server était une fonctionnalité majeure lors de la sortie de SQL Server 2014. Comme prévu avec une nouvelle fonctionnalité implémentée, il y avait un large éventail de limitations dans la version initiale et cela a empêché de nombreux clients d'adopter la technologie. Avec SQL Server 2016, un grand nombre de ces limitations ont été soit augmentées à un seuil plus élevé, soit complètement supprimées. Le InMemory OLTP a reçu la maturité et l'extension requises dans son ensemble de fonctionnalités pour le rendre viable pour un déploiement de production principal.
• R dans SQL Server : L'analyse des données a été le sujet le plus brûlant de l'informatique au cours des dernières années, de nouveaux créneaux étant couronnés comme le summum de la science de l'information presque aussi vite que la technologie peut progresser. Cependant, l'informatique dispose de quelques classiques résolus ayant résisté à l'épreuve du temps et sont toujours largement utilisés. Le SQL (dans ses nombreuses permutations) est un langage que nous connaissons bien dans le monde SQL Server. Un autre langage de ce type est le langage succinctement intitulé R. Le langage R est un langage d'exploration de données, d'apprentissage automatique et d'analyse statistique existant depuis 1993. De nombreux professionnels portant des titres tels que Data Scientists, Data Analyst ou statisticien utilisent le langage de programmation R et les outils appartenant à ce domaine depuis. Microsoft a identifié que, bien qu'ils puissent vouloir toutes les données du monde dans SQL Server, ce n'est tout simplement pas faisable ou raisonnable. Des sources de données externes et des langages tels que R existent et doivent être accessibles de manière intégrée. Pour que cela fonctionne, Microsoft a pris la décision d'acheter Revolution Analytics (une entité commerciale produisant le branche Revolution R) en 2015, ce qui leur a permis d'intégrer le processus de langage de programmation et de serveur à partir de SQL Server 2016. Cette intégration permet au développeur T-SQL normal d'interagir avec le service R extrêmement puissant de manière native et permettre une analyse de données plus avancée sur leurs données.

Concurrence

Au niveau des bases de données propriétaires, les principaux concurrents dans sa catégorie sont DB2, Informix, Oracle, PostgreSQL et Sybase.

Bibliothèques ou cadre d'application

Voici les principales bibliothèques ou cadres d'application pour communiquer avec SQL Server en fonction des langages de programmation :

Voir également

Article - Pourquoi une base de données perd ses données ?
Articles - Les géants de l'informatique - Microsoft