Un peu de mon expérience dans le monde .NET
| | Sun | Mon | Tue | Wed | Thu | Fri | Sat |
|---|
| 28 | 1 | 2 | 3 | 4 | 5 | 6 | | 7 | 8 | 9 | 10 | 11 | 12 | 13 | | 14 | 15 | 16 | 17 | 18 | 19 | 20 | | 21 | 22 | 23 | 24 | 25 | 26 | 27 | | 28 | 29 | 30 | 31 | 1 | 2 | 3 | | 4 | 5 | 6 | 7 | 8 | 9 | 10 |
Search
Navigation
Categories
Blogroll
|
Thursday, December 17, 2009
Interrogation du schéma d’une instance de DB
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é.
Thursday, December 17, 2009 3:44:32 PM (GMT Standard Time, UTC+00:00) SQL-Server | SQL-Server 2005
Tuesday, February 24, 2009
Friday, January 18, 2008
SQL Server Compact Merge replication
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
Friday, January 18, 2008 3:42:24 PM (GMT Standard Time, UTC+00:00) Windows Mobile | SQL-Server