67
4.1 Modélisation de la base de données
Le schéma se voit dans la vue système sys.xml_schema_collections, ou dans
l’explorateur d’objets de SSMS, dans une base de données, dans le dossier Programmability/Types/XML Schema Collections. On l’appelle une collection de schémas,
parce que plusieurs schémas peuvent être utilisés, de façon complémentaire, pour
valider le même document ou fragment. Vous pouvez ensuite créer une table qui
contient une colonne de type XML, validée par cette collection de schémas :
CREATE TABLE [Person].[Contact](
[ContactID] [int] IDENTITY(1,1) NOT NULL,
-- ...
[AdditionalContactInfo]
[xml]([Person].[AdditionalContactInfoSchemaCollection]) NULL
);
Nous obtenons alors une colonne XML typée, par opposition à une colonne non
validée par un schéma, dite non typée. La collection de schémas est une contrainte
de colonne, au même titre qu’une contrainte CHECK, par exemple. On pourrait se dire
que la validation par le schéma est une étape supplémentaire effectuée par le moteur,
et qu’elle est donc nuisible aux performances. En réalité, c’est le contraire. Comme
pour la contrainte CHECK, la vérification est effectuée à l’écriture dans la colonne (et
selon la complexité de la collection de schémas, cette étape peut se révéler coûteuse), mais on lit en général plus souvent que l’on écrit. Par ailleurs, à l’extraction,
SQL Server pourra s’appuyer sur les informations fournies par la contrainte pour
faciliter son travail. Le schéma fournit des informations précises sur le type de données des items dans le XML, ce qui permet à SQL Server de stocker l’instance XML
sous une forme binaire (un blob XML) au lieu d’une représentation textuelle, ce qui
rend la colonne XML beaucoup plus compacte. Les valeurs atomiques sont aussi stockées avec leur type de données (l’information de type est donnée dans la collection
de schéma), ce qui permet un parsing beaucoup plus efficace. Enfin, la vérification de
la validité d’une requête XQuery par rapport aux types de valeurs peut être vérifiée à
sa compilation, et des optimisations peuvent être effectuées. Le typage améliore
aussi l’efficacité des index XML 1 . Bref, cherchez autant que possible à créer des
colonnes XML typées.
Vous pouvez indexer vos colonnes XML, ce qui crée une représentation interne en
table relationnelle, et crée un index B-Tree sur cette structure. Pour plus d’information sur la structure des index, reportez-vous à la section 6.1.
Types divers
Il existe un type de données dont nous ne devrions même pas parler ici, tant il est à
éviter : sql_variant. Comme son nom l’indique, il correspond à un variant dans les
langages comme Visual Basic, c’est-à-dire qu’il adapte automatiquement son type
1. Plus d’infos dans l’article Technet « Performance Optimizations for the XML Data Type in SQL
Server 2005 » sur http://msdn.microsoft.com/en-us/library/ms345118.aspx.
4.1 Modélisation de la base de données
Le schéma se voit dans la vue système sys.xml_schema_collections, ou dans
l’explorateur d’objets de SSMS, dans une base de données, dans le dossier Programmability/Types/XML Schema Collections. On l’appelle une collection de schémas,
parce que plusieurs schémas peuvent être utilisés, de façon complémentaire, pour
valider le même document ou fragment. Vous pouvez ensuite créer une table qui
contient une colonne de type XML, validée par cette collection de schémas :
CREATE TABLE [Person].[Contact](
[ContactID] [int] IDENTITY(1,1) NOT NULL,
-- ...
[AdditionalContactInfo]
[xml]([Person].[AdditionalContactInfoSchemaCollection]) NULL
);
Nous obtenons alors une colonne XML typée, par opposition à une colonne non
validée par un schéma, dite non typée. La collection de schémas est une contrainte
de colonne, au même titre qu’une contrainte CHECK, par exemple. On pourrait se dire
que la validation par le schéma est une étape supplémentaire effectuée par le moteur,
et qu’elle est donc nuisible aux performances. En réalité, c’est le contraire. Comme
pour la contrainte CHECK, la vérification est effectuée à l’écriture dans la colonne (et
selon la complexité de la collection de schémas, cette étape peut se révéler coûteuse), mais on lit en général plus souvent que l’on écrit. Par ailleurs, à l’extraction,
SQL Server pourra s’appuyer sur les informations fournies par la contrainte pour
faciliter son travail. Le schéma fournit des informations précises sur le type de données des items dans le XML, ce qui permet à SQL Server de stocker l’instance XML
sous une forme binaire (un blob XML) au lieu d’une représentation textuelle, ce qui
rend la colonne XML beaucoup plus compacte. Les valeurs atomiques sont aussi stockées avec leur type de données (l’information de type est donnée dans la collection
de schéma), ce qui permet un parsing beaucoup plus efficace. Enfin, la vérification de
la validité d’une requête XQuery par rapport aux types de valeurs peut être vérifiée à
sa compilation, et des optimisations peuvent être effectuées. Le typage améliore
aussi l’efficacité des index XML 1 . Bref, cherchez autant que possible à créer des
colonnes XML typées.
Vous pouvez indexer vos colonnes XML, ce qui crée une représentation interne en
table relationnelle, et crée un index B-Tree sur cette structure. Pour plus d’information sur la structure des index, reportez-vous à la section 6.1.
Types divers
Il existe un type de données dont nous ne devrions même pas parler ici, tant il est à
éviter : sql_variant. Comme son nom l’indique, il correspond à un variant dans les
langages comme Visual Basic, c’est-à-dire qu’il adapte automatiquement son type
1. Plus d’infos dans l’article Technet « Performance Optimizations for the XML Data Type in SQL
Server 2005 » sur http://msdn.microsoft.com/en-us/library/ms345118.aspx.