VSDOTNET - SQL-Server

Interrogation du schéma d’une instance de DB

Stéphane Schwartz — Thu, 17 Dec 2009 15:44:32 GMT

MS a introduit, avec SQL-Server 2005 et les schémas de DB, de nouveaux vecteurs d’interrogation de la structure d’une instance de DB. Voici un petit état de lieu.

Les vues aux normes SQL2

Chaque instance est dorénavant affublée d’un nouveau schéma : INFORMATION_SCHEMA. Il permet d’interroger les informations en utilisant un point d’entrée central, puis en spécifiant l’information recherchée (tables, views, routines, ..), avec une syntaxe « utilisateur »

SELECT
*
FROM
INFORMATION_SCHEMA.TABLES

Les vues systèmes (DMV Dynamic Management Views)

Un deuxième schéma est automatiquement ajouté à chaque instance : SYS. L’interrogation se fait via des vues fournies par MS. Le niveau d’abstraction est moindre, mais ne nombre d’informations accessibles est supérieur.

SELECT
    *
FROM
    SYS.OBJECTS T1
WHERE
    T1.type = ‘U’

Les procédures stockées spécialisées

MS fournit un certain nombre de procédures stockés permettant d’interroger les informations, tels que sp_tables, sp_columns, …

EXEC sp_tables

Les tables systèmes

L’interrogation se fait cette fois au niveau le plus bas disponible. Les données sont brutes et relativement difficile à interpréter …

SELECT
    *
FROM
    SYSOBJECTS T1
WHERE
    T1.type = ‘U’

Conclusion

Les quatre méthodes de query de l’information retournent le même résultat, soit la liste des tables d’une DB. Mais alors quelle méthode utiliser en priorité ? La réponse, et l’explication est relativement simple :
1)    Les vues aux normes SQL2
2)    Les vues systèmes (DMV Dynamic Management Views)
3)    Les procédures stockées spécialisées
4)    Les tables systèmes
Et pourquoi ?
1)    Vous l’aurez compris, chaque niveau encapsule le niveau suivant. Les vues aux normes SQL2 sont donc plus faciles à utiliser car elles « cachent » la complexité du bas niveau.
2)    Seuls les vues et les SPs sont compatibles de version en version. Il est donc évident de les préférer pour des raisons de compatibilité.

Mappage des types SQL et CLR (LINQ)

Stéphane Schwartz — Tue, 24 Feb 2009 12:51:08 GMT

Un article msdn expliquant le mappage utilisé par LINQ entre les types SQL et CLR.

La partie la plus intéressant reste la matrice montrant quels types SQL est compatible avec quels type CLR. Le mappage n'est évidement pas de type 1:1.

SQL Server Compact Merge replication

Stéphane Schwartz — Fri, 18 Jan 2008 15:42:24 GMT

Je compulse actuellement le livre Windows Mobile Data Synchronization with SQL Server and SQL Server Compact 3.1 de Rob Tiffany, principalement pour appréhender la synchronisation de données entre un PPC et une base centralisée.

Rob donne un coup de projecteur sur une utilisation assez surprenante du Merge Replication. Comme 99% des personnes, je pense à cette technologie pour maintenir à jour des données et structures sur un PPC et une base SQL-Server centralisée. Rob pousse la réflexion plus loin et propose d’utiliser cette technologie pour pousser toutes sortes d’information sur le PPC. Et donc pourquoi pas des applications ou des policies ?

L’exemple est trop simple et on se demande pourquoi ne pas y avoir pensé avant …

Le PPC est abonné (Subscription) à un article (Article). Au niveau physique, le PPC est abonnée à une table avec un champ. Un niveau serveur, on renseigne ce champ avec l’application (en binaire). A la prochaine connexion, l’application est poussée sur la PPC par le serveur de réplication. Supposons qu’un agent tourne sur le PPC et se charge d’installer les applications trouvées dans cette table, et le tour est joué ! Même principe pour des settings systeme ...

C’est tellement simple que j’ai presque envie de faire le test !

Stéphane