Conception et performances d'une base de données (SQL Server Compact)

Vous pouvez améliorer de façon significative les performances de votre application SQL Server Compact 3.5 (SQL Server Compact 3.5) en concevant correctement la base de données SQL Server et la publication. Les sections ci-dessous présentent les techniques que vous pouvez utiliser pour améliorer les performances.

Utilisation de la dénormalisation d'une base de données

Une base de données normalisée empêche des dépendances fonctionnelles au niveau des données de sorte que la mise à jour de la base de données soit simple et efficace. Toutefois, l'interrogation de la base de données peut nécessiter de nombreuses jointures de tables pour combiner les informations. Lorsque le nombre de tables de jointure augmente, le temps d'exécution de la requête s'accroît de façon significative. Pour cette raison, une base de données normalisée ne constitue pas toujours la meilleure solution. Une base de données quelque peu dénormalisée réduit le nombre de tables qui doivent être jointes sans que le processus de mise à jour devienne trop compliqué. Il s'agit souvent d'un bon compromis.

Remarque :
En règle générale, si un nombre significatif de vos requêtes nécessitent la jointure de plus de cinq ou six tables, vous devez envisager la dénormalisation.

Il existe d'autres types de dénormalisations de base de données. Par exemple, supposons qu'une base de données contienne les deux tables suivantes : Orders et Order Details. La table Orders contient des informations sur la commande d'un client. Les produits de chaque commande sont contenus dans la table Order Details. Imaginons que vous souhaitiez déterminer le montant total de chaque commande. Vous devez d'abord déterminer le montant de chaque produit (units (nombre d'unités) * unit price (prix unitaire) – applicable discount (remise applicable)), puis regrouper les montants par commande. Voici un aperçu de la requête :

SELECT "Order ID", SUM("Unit Price" * Quantity * (1.0 - Discount))

AS Total FROM "Order Details"

GROUP BY "Order ID"

Order ID Total

----------------------------------------

10000 108

10001 1363.15000915527

10002 731.800003051758

10003 498.180023193359

10004 3194.19999694824

10005 173.400009155273

10006 87.2000007629395

10007 1405

10008 1171

10009 1530

10010 470

... ...

(1078 rows affected)

Le calcul effectué par cette requête est complexe. Si l'ensemble des commandes est important, l'exécution de la requête peut prendre un certain temps. Une autre solution consiste à calculer le montant de la commande au moment où elle est effectuée, puis à le stocker dans une colonne de la table Orders. Grâce à cette solution, seule la colonne précalculée doit être interrogée pour renvoyer les informations dont vous avez besoin :

SELECT "Order ID", "Order Total" AS Total FROM Orders

En créant une colonne précalculée, vous pouvez accélérer la requête, mais cette solution nécessite la gestion d'une colonne supplémentaire dans la table.

Choix entre des colonnes de longueur fixe ou variable

Lorsque vous créez des tables, il est important de connaître les avantages et les inconvénients de l'utilisation des colonnes de longueur fixe par rapport aux colonnes de longueur variable. Les colonnes dont la longueur est variable permettent de réduire la taille de la base de données, car elles utilisent uniquement l'espace nécessaire pour stocker la valeur actuelle. En revanche, les colonnes dont la longueur est fixe utilisent toujours l'espace maximal défini par le schéma, même si la valeur actuelle est vide. L'inconvénient de l'utilisation des colonnes de longueur variable est que certaines opérations ne sont pas aussi efficaces que lorsqu'elles sont effectuées sur des colonnes de longueur fixe. Par exemple, si une colonne de longueur variable, à l'origine peu volumineuse, s'accroît de façon significative suite à une opération UPDATE, l'enregistrement risque de devoir être placé à un autre endroit. En outre, les mises à jour fréquentes entraînent une fragmentation plus importante des pages de données au fil du temps. Pour cette raison, il est recommandé d'utiliser des colonnes de longueur fixe lorsque la longueur des données varie peu et que des mises à jour sont effectuées fréquemment.

Création de lignes de plus petite taille

Le nombre de lignes qu'une page peut contenir dépend de la compacité de chaque ligne. Une page peut contenir davantage de lignes si celles-ci sont peu volumineuses. Dans ce cas, une seule opération disque sur une table qui contient des lignes compactes peut extraire davantage de lignes et accroître l'efficacité de l'opération. En outre, davantage de lignes peuvent être contenues dans le cache du moteur de stockage, ce qui peut éventuellement augmenter le taux d'accès. Des lignes compactes permettent également de rationaliser l'espace dans les pages de données. Des lignes plus volumineuses entraînent couramment des espaces inutilisés.

Supposons l'exemple extrême suivant : si la taille de l'enregistrement est supérieure à la moitié d'une page de données, presque la moitié de l'espace de chaque page est inutilisée. Certains concepteurs de base de données choisissent de créer des tables volumineuses et d'appliquer le schéma de base de données de grand système à l'appareil. Cette conception risque de ne pas être efficace. Une solution possible consiste à diviser les tables les plus importantes. Supposons qu'une table contienne quelques colonnes avec des valeurs très stables et d'autres colonnes avec des valeurs qui changent fréquemment. Il paraît logique de diviser la table en deux : une table qui contient les colonnes référencées fréquemment et une table avec les colonnes stables. En créant deux tables, vous bénéficiez de tous les avantages des lignes de longueur plus petite. L'inconvénient de cette solution est qu'une jointure est requise pour combiner les informations.

Utilisation de clés de longueur plus petite

Un index est un sous-ensemble trié de la table sur laquelle il est créé. Il permet des recherches de plages et des ordres de tri rapides. Les petites clés d'index occupent moins d'espace et sont plus efficaces que des clés plus grandes. Il est vivement conseillé de faire en sorte que la clé primaire soit compacte, car elle est souvent référencée en tant que clé étrangère dans d'autres tables. S'il n'existe pas de clé primaire compacte, vous pouvez utiliser à la place une colonne d'identité implémentée sous forme d'entier.

Un index qui comporte seulement une ou quelques colonnes d'index est appelé un index réduit. Un index qui comporte de nombreuses colonnes d'index est appelé un index étendu. Un index étendu est souvent associé à une clé de grande longueur. Un exemple extrême est un index qui contient chaque colonne d'une table. En créant un tel index, vous faites en réalité un double de la table d'origine. Ce type d'index est inefficace en termes de taille de base de données et de performances des requêtes.

Options et types d'articles de publication

Lorsque vous créez une publication dans SQL Server 2008, vous pouvez choisir deux options pour les articles dans votre publication. Ces options, qui contrôlent le filtrage et le flux de données entre le serveur de publication et l'Abonné, sont les suivantes :

• Téléchargement seul (lecture seule)
  Dans certains cas, vous souhaiterez que les données de l'appareil de type « smart device » soient stockées dans des tables de correspondance uniquement. Par exemple, vos utilisateurs peuvent avoir besoin de consulter le répertoire de leur société sur leur appareil de type « smart device » sans être en mesure de modifier ces informations. Le type d'article en téléchargement seul est adapté à ce cas. Il est en outre moins volumineux, car aucune métadonnée n'est stockée sur l'appareil, et il permet de réduire le trafic réseau au cours de la synchronisation.
• Correctement partitionné
  Dans le cas d'articles correctement partitionnés dans SQL Server 2008, les modifications qui sont téléchargées vers un serveur sont mappées uniquement sur l'ID de partition unique. Cette méthode est plus rapide, mais elle présente les restrictions suivantes :
  • Chaque ligne de l'article ne doit appartenir qu'à un seul ID de partition.
  • Chaque article ne peut être publié que dans une seule publication.
  • L'Abonné ne peut pas ajouter de lignes qui n'appartiennent pas à son ID de partition.
  • Le filtrage est également affecté lors de l'utilisation d'articles correctement partitionnés Les restrictions suivantes s'appliquent au filtrage :
  • Un Abonné ne peut pas mettre à jour des colonnes qui sont impliquées dans le filtrage.
  • Dans une hiérarchie de filtres de jointure, un article standard ne peut pas être un article parent d'un article correctement partitionné.
  • Le mot clé du filtre de jointure join_unique_key dans lequel un article correctement partitionné est un article enfant doit avoir la valeur 1.
  • Chaque article ne peut posséder qu'un filtre de sous-ensemble ou un filtre de jointure. L'article peut posséder un filtre de sous-ensemble et être l'article parent d'un filtre de jointure mais ne peut pas posséder un filtre de sous-ensemble et être l'article enfant d'un filtre de jointure.

Voir aussi

Concepts

Réglage des performances des requêtes (SQL Server Compact)

Autres ressources

Amélioration des performances (SQL Server Compact)

Aide et informations

Obtention d'aide (SQL Server Compact 3.5 Service Pack 1)