> Tech > Yukon : Une mine d’or

Yukon : Une mine d’or

Tech - Par iTPro - Publié le 24 juin 2010
email

Déjà 13 pépites

Yukon, dont la livraison est prévue fin juin pour la version beta et fin novembre pour la version finale, est la dernière version de Microsoft SQL Server. Il marque la fin d’un cycle de développement de 5 ans pour Microsoft ...La firme a ajouté tellement de nouvelles fonctions à Yukon qu’il est impossible de les énumérer toutes dans un seul article. Voici donc 13 pépites d’or que l’on risque fort de trouver dans la prochaine release notable de SQL Server.

Yukon : Une mine d’or

Sans aucune doute, la nouvelle fonction de Yukon la plus marquante est l’intégration
de CLR (Common Language Runtime) de Windows .NET Framework avec le
moteur de base de données SQL Server. Une telle intégration permet aux développeurs
et aux administrateurs de bases de données (DBA) de créer des objets
base de données SQL Server, tels que procédures stockées, déclencheurs, UDF
(user-defined functions) et agrégats. Cette nouvelle fonction comble l’une des
rares lacunes restantes – à  savoir, l’incapacité d’utiliser un langage OOP pour créer
des objets base de données – dont SQL Server souffrait par rapport aux bases de
données relationnelles concurrentes, comme DB2 et Oracle. Avec Yukon, vous
pouvez utiliser Visual Basic .NET, Visual C# .NET, Visual C++ .NET, Visual# .NET
ou tout autre langage compatible .NET
pour créer des objets base de données.
Comme les langages .NET sont modernes
et entièrement orientés objet
(OO), ils sont mieux à  même de régler
des problèmes de gestion complexes
que le langage T-SQL procédural.
Pour utiliser cette nouvelle fonction,
vous devez créer un ensemble en
utilisant un nouveau type de projet
SQL Server que Whidbey, la prochaine
version de Visual Studio .NET fournira. (Microsoft envisage d’annoncer Whidbey
en même temps que Yukon.) Ensuite, vous allez charger cet ensemble dans Yukon
et utiliser une version étendue de l’instruction CREATE PROCEDURE, TRIGGER or FUNCTION de T-SQL pour créer le nouvel objet base de données
basé sur .NET.
L’intégration de CLR avec le moteur de base de données
SQL Server est bien plus qu’un léger habillage : le moteur de
base de données héberge en réalité le CLR en cours de traitement.
Yukon gère la mémoire selon les besoins. Les objets
base de données CLR accèdent à  la base de données SQL
Server en utilisant une version mise à  jour d’ADO.NET
conjointement à  un nouveau SQL Server .NET Data Provider.
Contrairement aux ensembles T-SQL, qui n’ont aucune
fonction native pour faire référence aux ressources à  l’extérieur
de la base de données, les ensembles .NET sont parfaitement
capables d’évaluer les ressources du système et du
réseau. C’est pourquoi il est important de développer des
ensembles .NET sécurisés.
Dans Yukon, Microsoft a intégré le modèle de sécurité
SQL Server basé sur l’utilisateur, avec le modèle de sécurité
CLR basé sur les permissions. En suivant le modèle de sécurité
SQL Server, les utilisateurs ne peuvent accéder qu’aux
objets base de données (y compris les objets d’ensembles
.NET) sur lesquels ils ont des droits utilisateur. Le modèle de
sécurité CLR étend cette mesure de sécurité en permettant
le contrôle sur le type de ressources système auxquelles peut
accéder le code .NET fonctionnant sur un serveur. C’est au
moment où vous créez l’ensemble que vous spécifiez les permissions
de sécurité CLR. Plus précisément, vous utilisez la
clause WITH PERMISSION_SET de l’instruction CREATE ASSEMBLY.
Le tableau 1 résume les permissions de sécurité de
base de données CLR que vous pouvez appliquer aux objets
base de données SQL Server.
Comme le montre le tableau 1, la permission SAFE restreint
tous les accès externes. La permission EXTERNAL_ACCESS
autorise quelques accès externes des ressources
par l’intermédiaire d’API gérées. Yukon imite l’appelant
pour accéder aux ressources. Pour créer des objets qui
utilisent cette permission, vous devez avoir la nouvelle
permission EXTERNAL_ACCESS. Seuls les administrateurs
système peuvent créer des objets avec la permission
UNSAFE parce que celle-ci autorise l’accès externe
à  toute ressource, y compris au système de registres de
fichiers.

Téléchargez gratuitement cette ressource

Sécurité Office 365 : 5 erreurs à ne pas commettre

Sécurité Office 365 : 5 erreurs à ne pas commettre

A l’heure où les données des solutions Microsoft de Digital Workplace sont devenues indispensables au bon fonctionnement de l’entreprise, êtes-vous certain de pouvoir compter sur votre plan de sécurité des données et de sauvegarde des identités Microsoft 365, Exchange et Teams ? Découvrez les 5 erreurs à ne pas commettre et les bonnes pratiques recommandées par les Experts DIB France.

Tech - Par iTPro - Publié le 24 juin 2010