index sur une table

Version imprimable

index sur une table

bonjour à tous,
voici une table que j'ai créé et j'aimerais savoir si mon index est efficasse et j'aimerais ajouter un second pour la clause where.

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
CREATE TABLE [dbo].[Sto_Imprime](
	[Numero_Operation] [char](10) NOT NULL,
	[Code_Type_Imprime] [char](1) NOT NULL,
	[Numero_Imprime] [char](10) NOT NULL,
	[Cout_Unitaire] [money] NOT NULL,
	[Code_Statut_Imprime] [char](2) NOT NULL,
	[Code_Magasin] [char](4) NOT NULL,
	[Code_Intermediaire] [char](4) NOT NULL,
	[Numero_Quittance] [char](16) NOT NULL,
	[Numero_Identification] [varchar](15) NOT NULL,
 CONSTRAINT [PK_Sto_Imprime] PRIMARY KEY NONCLUSTERED 
(
	[Numero_Operation] ASC,
	[Code_Type_Imprime] ASC,
	[Numero_Imprime] ASC
)WITH (PAD_INDEX  = OFF, STATISTICS_NORECOMPUTE  = OFF, IGNORE_DUP_KEY = OFF, ALLOW_ROW_LOCKS  = ON, ALLOW_PAGE_LOCKS  = ON, FILLFACTOR = 70) ON [PRIMARY]
) ON [PRIMARY]

s'il vous plait dite moi quel est le second index que je peux mettre sur cette table car mon application devient de plus en plus lente.
Mercid de votre soutient !

28/05/2013, 13h21
DotNetMatt

Indépendament de l'index, déjà une bonne chose serait de ne pas utiliser des types CHAR ou VARCHAR pour des donées numériques. L'utilisation de types appropriés permettra sûrement d'accélérer les choses...

Ensuite, vu le DDL posté, il n'y a aucune clef étrangère.

Il y a donc un problème de modélisation à la base.

Ensuite pour les index, il faut les positionner judicieusement, notamment sur les colonnes qui servent à filtrer dans les clauses WHERE, et sur celles qui servent aux jointures (les clefs étrangères).
Donc en gros, pour décider si oui ou non il faut un index sur une colonne, il faut regarder l'utilisation qui en est faite...
05/06/2013, 13h22
WOLO Laurent
La lenteur au niveau de ton application peut etre engendre par plusieurs problemes.
Commence par determiner le talon d'Achile de ton application qui peut etre :
1. La lenteur de ton application (Mauvais design de ta couche de presentation, business ou d'acces au donnees);
2. La lenteur de ta base de donnees (Lenteurs d'execution des requetes);
3. Le manque de ressources de ton serveur de base de donnees
05/06/2013, 13h31
SQLpro

De plus une PK composée de 3 colonnes avec en tout 21 octets, c'est parfaitement dégueulasse en terme de performances....
En sus, cette PJ est sémantique, alors que par principe, pour de bonnes performances et pour une évolution aisée de mon modèle, il faudrait utiliser TOUJOURS des clef primaires asémantique, comme les auto incréments.

A +