Microsoft SQL Server est un système de gestion de base de données (SGBD) en langage SQL incorporant entre autres un SGBDR (SGBD relationnel ») développé et commercialisé par la société Microsoft. Il fonctionne sous les systèmes d'exploitation Microsoft Windows et Linux (depuis ), mais il est possible de le lancer sur macOS via Docker, car il en existe une version en téléchargement sur le site de Microsoft..
Historique
Bien qu'il ait été initialement codéveloppé par Sybase et Microsoft, Ashton-Tate a également été associé à sa première version, sortie en 1989. Cette version est sortie sur les plates-formes Unix et OS/2. Depuis, Microsoft a porté ce système de base de données sous Microsoft Windows.
Lors de sa création, Sybase SQL Server hérite des principes du moteur Ingres développé à l'origine par l'université de Berkeley.
En 1994, le partenariat entre les deux sociétés ayant été rompu, Microsoft a sorti la version 6.0 puis 6.5 seul, sur la plate-forme Windows NT. Microsoft a continué de commercialiser le moteur de base de données sous le nom de SQL Server Tandis que Sybase, pour éviter toute confusion, a renommé Sybase SQL Server en Sybase Adaptive Server Enterprise.
Microsoft SQL Server fait désormais partie de la stratégie technique de Microsoft en matière de base de données. Le moteur MSDE, qui est la base de SQL Server, doit à terme remplacer le moteur Jet (celui qui gère les bases Access) dans les applications telles que Exchange et Active Directory.
La version 2005 de SQL Server est sortie le en même temps que Visual Studio 2005. La prise en charge de Windows Vista et de Windows Server 2008 n'a été ajoutée qu'à partir du Service Pack 2 (SP2). Actuellement le Service Pack 3 est disponible. L'optimiseur a été entièrement refait, tout comme le moteur relationnel.
La version 2008 de SQL Server (nom de code Katmaï) est sortie en août 2008. La version mineure 2008 R2 est sortie en 2010.
La version 2012 de SQL Server est sortie en avril 2012.
La version 2014 de SQL Server est sortie le avec un moteur « in memory » complémentaire au moteur relationnel.
La version 2016 de SQL Server est sortie le .
La version 2017 de SQL Server est sortie le .
La version 2019 de SQL Server est sortie le .
La version 2022 de SQL Server est sortie le .
Lors du développement de la version 2005, le projet était à l'époque l'un des plus grands projets informatiques du monde. Plus de développeurs ont participé au codage du noyau et l'on estime que plus de autres personnes y ont travaillé de près ou de loin (Interactions homme-machine, documentation, traduction...).
Particularités SQL Server se distingue de la concurrence par une grande richesse ne nécessitant aucune option payante supplémentaire dans la limite de la version choisie.
Multi-base, multi-schéma Par rapport à ses concurrents que sont Oracle, MySQL ou PostgreSQL, SQL Server se distingue par le fait que c'est un SGBDR(Système de Gestion de Bases de Données Relationnelles) originellement multibase et multischéma. Il est possible de faire des requêtes nativement interbases. Par exemple la requête suivante lie deux tables de deux bases de données différentes : SELECT * FROM BASE_A.dbo.TABLE1 AS T1 INNER JOIN BASE_B.dbo.TABLE2 AS T2 ON T1.ID = T2.ID; L'optimiseur étant capable de faire un plan de requête parfaitement optimisé même si la requête consulte des données de plusieurs bases...
Bien que PostgreSQL soit multibase et multischéma, cette possibilité d'interrogation simultanée n'est pas native et il faut passer par le truchement de "dblink" qui interdit les jointures et donc toute possibilité d'optimisation... Oracle avec sa version 12 tente d'intégrer ce même concept de multibase (appelé multi-tenant) mais souffre du même problème que PostgreSQL. MySQL est mono schéma, multibase.
Gestion des schémas SQL La souplesse de la gestion des schémas SQL est telle qu'il est possible de transférer un objet d'un schéma à l'autre par le simple biais d'une commande ALTER SCHEMA.
Les propriétaires sont distincts des schémas et il est possible de transférer la propriété d'une base, d'un schéma ou d'un objet d'un utilisateur SQL à l'autre, par le biais de la commande ALTER AUTHORIZATION.
Parallélisme SQL Server fonctionne nativement de manière parallèle. Dès qu'une requête est estimée dépasser le seuil du coût à partir duquel un plan de requête peut être parallélisé, SQL Server récrit le plan en utilisant des algorithmes multi-threadés et si le nouveau plan s'avère moins couteux, la substitution a lieu de manière automatique. Cette fonctionnalité existe dans toutes les éditions et n'est pas un module payant à rajouter en sus comme c'est le cas d'Oracle.
Les opérations de lecture et d'écriture physique bénéficient aussi du parallélisme systématiquement du fait que les opérations d'IO sont effectuées directement par SQL Server et non à travers la couche système comme c'est le cas de PostgreSQL ou MySQL.
Compression Dans l'édition Enterprise, ou dans toutes les éditions à partir d'SQL Server 2016 SP1 ou d'SQL Server 2017 et versions ultérieures, le moteur est capable de compresser les données au niveau ligne ou page dans les tables comme dans les index. La compression des sauvegardes est disponible à partir de l'édition standard depuis la version 2008 R2.
Sauvegarde à chaud Depuis SQL Server 7 (1998), SQL Server permet de sauvegarder "base ouverte", sans interrompre le service des données et sans perturber l'activité des utilisateurs. Cette sauvegarde peut s'effectuer de manière globale, par groupe de fichiers, par fichiers ou par le biais du journal de transaction.
Unique... sauf NULL ! Dans SQL Server, les contraintes d'unicité prennent en compte le marqueur NULL comme étant une valeur et par ce fait interdisent donc la présence de plusieurs NULL dans les colonnes d'une telle contrainte. Ceci n'est pas conforme à la norme SQL puisque le NULL étant une absence de valeur, l'unicité ne se pose pas. Il existe cependant un moyen simple de contourner ce problème, qui consiste à créer un index unique filtré qui concernera les données valuées.
Exemple, soit la table : CREATE TABLE T_EMPLOYE_EMP (EMP_ID INT PRIMARY KEY, EMP_NOM VARCHAR(32) NOT NULL, EMP_MATRICULE CHAR(8)); Comme le matricule doit être unique pour les valeurs connues, la création d'un index unique filtré sur les valeurs exprimées de la colonne matricule, permet de résoudre le problème : CREATE UNIQUE INDEX X_EMP_MATRICULE ON T_EMPLOYE_EMP(EMP_MATRICULE) WHERE EMP_MATRICULE IS NOT NULL;
Déclencheurs ré-entrants (table "mutante") Dans les déclencheurs SQL Server (triggers) il est possible de mettre à jour la table cible de l'événement à l'origine de l'exécution du déclencheur, contrairement à de nombreuses bases qui interdisent cette possibilité (erreur de "table mutante" dans Oracle). Il faut se rappeler que c'est Sybase qui, à l'origine a inventé le concept de trigger en 1986, mettant ainsi pour la première fois du code exécutable dans une base de données relationnelle.
Par exemple un déclencheur UPDATE sur une table peut modifier les données en instance de modification :
CREATE TRIGGER E_U_PERSONNE ON T_PERSONNE_PRS FOR UPDATE AS IF UPDATE(PRS_NOM) UPDATE T_PERSONNE_PRS SET PRS_NOM = UPPER(PRS_NOM) WHERE PRS_ID IN (SELECT PRS_ID FROM inserted); Dans l'exemple ci-avant, les noms des personnes nouvellement insérées ou dont le nom est modifié est remis en majuscule.
La réentrance pouvant conduire à la récursivité, différents paramétrages permettent de régler ce problème au niveau de la base, comme au niveau de l'instance.
Vues indexées automatisées Contrairement à Oracle ou PostgreSQL où les vues matérialisées doivent la plupart du temps être rafraichies avant utilisation, les vues indexées de SQL Server sont toujours synchrones. De plus l'optimiseur est capable de substituer à la volée la vue indexée à tout ou partie de la requête (version Enterprise) ce qui est très pratique lorsque le DBA n'a pas accès au code des programmes clients (cas des applications d'éditeurs).
Pooling automatique Pour les applications conçues dans .net et utilisant le connecteur ADO, SQL Server effectue du pooling automatique. Le simple fait de distinguer deux chaines de connexion suffit à créer deux pools différents. Pour que le pooling soit efficace, il faut fermer les connexions, une fois le traitement informatique opéré.
Administration centralisée Par différents biais, SQL Server permet de gérer de manière centralisée un ensemble de serveur. Vous pouvez créer un serveur d'administration centralisée, et ajouter une liste de serveurs SQL de l'entreprise afin de lancer des requêtes envoyées simultanément sur tous les serveurs ou bien créer ou exécuter une même procédure sur tous les serveurs à la fois, ceci dans l'outil SSMS (SQL Server Management Studio)..
De la même façon, le planificateur de tâche et gestionnaire d'alerte (l'Agent SQL) permet de définir des travaux multi-serveurs, comme la sauvegarde, la défragmentation des index le recalcul des statistiques ou la vérification d'intégrité physique des espaces de stockage.
Fonctionnalités pour le développement Le moteur OLTP de SQL Server est doté de très nombreuses fonctionnalités qu'il serait difficile de toutes énumérer. En voici quelques-unes qui font la différence avec des SGBD plus légers comme MySQL ou PostgreSQL...
Table, index et procédure "In Memory" SQL Server est doté d'un moteur "In Memory" depuis la version 2014. Les tables et index peuvent être totalement en mémoire (structure et données : data and schema) ou persistantes au niveau de la structure (data only). Les procédures, dans des limites bien définies, peuvent être compilées en mode natif, plutôt qu'interprétées. Les mises à jour restent transactionnées, sans pour autant qu'il soit besoin d'écrire dans les fichiers du journal de transactions (versionnage "in memory"), Cela permet des améliorations très sensibles de performance pour des traitements de calculs complexes portant sur des volumes conséquents de données. Un exemple typique est le calcul des performances financières des cours de bourses en temps réel.
Intra jointure (APPLY) SQL Server a été le premier avec la version 2005 a introduire l'opérateur d'intra-jointure APPLY afin de faciliter la récupération des données encapsulées dans une table virtuelle d'une colonne de table, comme c'est le cas lorsque l'on utilise une fonction table dans une requête dont un des arguments vient d'une des tables de la requête, ou encore lorsque l'on tabularise du XML. L'opérateur APPLY doit être précédé du mot clef CROSS ou OUTER afin d'en définir le comportement. Avec CROSS si l'argument est NULL, les lignes concernées sont supprimées du résultat tandis qu'avec OUTER elles sont préservées.
L'opérateur APPLY est voisin de l'opérateur LATERAL de la norme SQL, mais sa syntaxe plus étendue permet des opérations que LATERAL ne peut pas réaliser. Oracle vient récemment d'introduire cet opérateur dans sa version 12.1 (2014). SELECT top 10 * FROM sys.dm_exec_query_stats AS qs CROSS APPLY sys.dm_exec_sql_text(qs.sql_handle) OUTER APPLY sys.dm_exec_query_plan(qs.plan_handle) ORDER BY total_worker_time DESCDans cet exemple, on utilise la fonction table sys.dm_exec_query_plan, qui restitue le plan d’exécution, à partir du "handle" de plan fournit par l'argument "plan_handle" présent dans la vue sys.dm_exec_query_stats. Cette requête permet de connaître les 10 requêtes ayant consommé le plus de temps CPU depuis le démarrage de l'instance.
Collations (interclassement des littéraux)