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 4.0 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.
Notes
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, supposez que vous avez deux tables dans une base de données : 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.
Considérez cet exemple : 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 est sensé de fractionner la table en deux tables : l'une avec les colonnes référencées fréquemment et l'autre 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.
Voir aussi
Concepts
Réglage des performances des requêtes (SQL Server Compact)