Performance d'une vue indexée

Version imprimable

23/04/2011, 23h06
hunter_X

Performance d'une vue indexée

Bsr à tous..
J'aimerais avoir votre avis d'expert sur ce sujet.
J'ai une table de base de données sql server 2008 R2 mise à jour chaque jour avec 1 000 000 d'enregistrements. Et je comptais créer une vue indexée filtrant certaines colonnes de la table.
Ma question est la suivante, en exploitant cette table pendant 6mois à quels problèmes puis-je être confrontés.
Merçi
24/04/2011, 08h01
mikedavem

Bonjour,

Il faudrait en premier lieu avoir la ddl de votre table concernes par la vue, les index associes et la ddl de votre vue.

++
24/04/2011, 08h54
iberserk

Dans les grandes lignes imaginez que votre vue indexée réagira comme si c'était une table comme une autres.

Les gains les plus interessant pour les vues indexées sont les requêtes faisant intervenir des agregats qui peuvent limiter de manière drastique les IO.

En revanche vos insertion/maj sur la table son pénalisés du fait de la nécessité de maintenir la vue indexée à jour...

Voyez ceci:
http://sqlpro.developpez.com/optimisation/indexation/
24/04/2011, 10h27
Ptit_Dje

Lorsque vous dites 6 mois, est ce la durée de rétention des données dans votre table ?
A priori 6 mois de données à 1M de row par jour vous fera environ 180M de lignes.
Selon la taille d'une ligne (il faut la DDL pour le dire) le volume de votre table risque vite de grossir.
Par soucis de maintenabilité et de performances, demandez vous si cette table n'est pas une bonne candidate au partitionning.
Prévoyez de l'espace disque en conséquence aussi.
24/04/2011, 12h55
iberserk

Citation:

demandez vous si cette table n'est pas une bonne candidate au partitionning

Et si votre edition d'SQL SERVER vous le permet bien! :ccool:

Merci à tous pour vos apports..

Voiçi la structure d'une des tables :

Code:

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
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
CREATE TABLE [dbo].[MOC](
	[id] [int] IDENTITY(1,1) NOT NULL,
	[recordno] [nvarchar](max) NULL,
	[recordType] [nvarchar](20) NULL,
	[servedIMSI] [nvarchar](20) NULL,
	[servedIMEI] [nvarchar](20) NULL,
	[servedMSISDN] [nvarchar](30) NULL,
	[callingNumber] [nvarchar](40) NOT NULL,
	[calledNumber] [nvarchar](40) NOT NULL,
	[recordingEntity] [nvarchar](30) NULL,
	[mscIncomingROUTE] [nvarchar](25) NULL,
	[mscOutgoingROUTE] [nvarchar](25) NULL,
	[location] [nvarchar](25) NULL,
	[basicService] [nvarchar](30) NULL,
	[msClassmark] [nvarchar](15) NULL,
	[answerTime] [nvarchar](15) NOT NULL,
	[releaseTime] [nvarchar](15) NULL,
	[callDuration] [nvarchar](15) NULL,
	[radioChanRequested] [nvarchar](35) NULL,
	[radioChanUsed] [nvarchar](35) NULL,
	[causeForTerm] [nvarchar](40) NULL,
	[diagnostics] [nvarchar](40) NULL,
	[callReference] [nvarchar](30) NULL,
	[additionalChgInfo] [nvarchar](40) NULL,
	[gsm_SCFAddress] [nvarchar](35) NULL,
	[serviceKey] [nvarchar](5) NULL,
	[networkcallReference] [nvarchar](25) NULL,
	[mSCAddress] [nvarchar](30) NULL,
	[speechVersionSupported] [nvarchar](5) NULL,
	[speechVersionUsed] [nvarchar](5) NULL,
	[numberOfDPEncountered] [nvarchar](5) NULL,
	[levelOfCAMELService] [nvarchar](30) NULL,
	[freeFormatData] [nvarchar](20) NULL,
	[systemType] [nvarchar](10) NULL,
	[classmark3] [nvarchar](10) NULL,
	[chargedParty] [nvarchar](15) NULL,
	[mscOutgoingCircuit] [nvarchar](10) NULL,
	[orgRNCorBSCId] [nvarchar](10) NULL,
	[globalAreaID] [nvarchar](30) NULL,
	[subscriberCategory] [nvarchar](25) NULL,
	[firstmccmnc] [nvarchar](15) NULL,
	[lastmccmnc] [nvarchar](15) NULL,
	[translatedNumber] [nvarchar](30) NULL,
	[serviceCentre] [nvarchar](30) NULL,
	[deliveryTime] [nvarchar](15) NULL,
	[smsUserDataType] [nvarchar](5) NULL,
	[originationnumber] [nvarchar](30) NULL,
	[messageReference] [nvarchar](5) NULL,
	[originationTime] [nvarchar](15) NULL,
	[destinationNumber] [nvarchar](30) NULL,
	[supplServicesUsed] [nvarchar](100) NULL,
	[roamingNumber] [nvarchar](30) NULL,
	[calledIMSI] [nvarchar](20) NULL,
	[sequenceNumber] [nvarchar](5) NULL,
	[mscIncomingCircuit] [nvarchar](10) NULL,
	[maximumNumberOfSMSInTheConcatenatedSMS] [nvarchar](5) NULL,
	[concatenatedSMSReferenceNumber] [nvarchar](5) NULL,
	[sequenceNumberOfTheCurrentSMS] [nvarchar](5) NULL,
	[partialRecordType] [nvarchar](30) NULL,
	[connectedNumber] [nvarchar](30) NULL,
	[originalCalledNumber] [nvarchar](30) NULL,
	[routingNumber] [nvarchar](30) NULL,
	[interrogationTime] [nvarchar](15) NULL,
	[mscIncomingRouteAttribute] [nvarchar](10) NULL,
	[mscOutgoingRouteAttribute] [nvarchar](10) NULL,
	[transparencyIndicator] [nvarchar](20) NULL,
	[fnur] [nvarchar](30) NULL,
	[modemType] [nvarchar](30) NULL,
	[redirectingnumber] [nvarchar](30) NULL,
	[redirectingcounter] [nvarchar](15) NULL,
	[IncomingROUTE] [nvarchar](25) NULL,
	[OutgoingROUTE] [nvarchar](25) NULL,
	[ChangeofLocation] [nvarchar](25) NULL,
	[ChangeOfService] [nvarchar](30) NULL,
	[SupplementaryServices] [nvarchar](30) NULL,
	[AOCParameters] [nvarchar](30) NULL,
	[ChangeofAOCPara] [nvarchar](30) NULL,
	[ChangeofClassmark] [nvarchar](10) NULL,
	[Eventtimestamps] [nvarchar](15) NULL,
	[ChangeofRadioChan] [nvarchar](35) NULL,
	[Causefortermination] [nvarchar](40) NULL,
	[Sequenceno] [nvarchar](5) NULL,
	[Recordextensions] [nvarchar](30) NULL,
	[gsmSCFaddress] [nvarchar](30) NULL,
	[CAMELinitiatedCFindicator] [nvarchar](25) NULL,
	[Defaultcallhandling] [nvarchar](15) NULL,
	[FixedNetworkUserRate] [nvarchar](25) NULL,
	[AirInterfaceUserRateRequested] [nvarchar](30) NULL,
	[CAMELcallleginformation] [nvarchar](40) NULL,
	[Freeformatdataappendindicator] [nvarchar](20) NULL,
	[Defaultcallhandling2] [nvarchar](15) NULL,
	[GsmSCFaddress2] [nvarchar](30) NULL,
	[Servicekey2] [nvarchar](5) NULL,
	[FreeformatData2] [nvarchar](5) NULL,
	[Freeformatdataappendindicator2] [nvarchar](20) NULL,
	[RateIndication] [nvarchar](40) NULL,
	[Guaranteedbitrate] [nvarchar](30) NULL,
	[Maximumbitrate] [nvarchar](30) NULL,
	[CallingChargeAreaCode] [nvarchar](30) NULL,
	[CalledChargeAreaCode] [nvarchar](30) NULL,
	[RNCorBSCId] [nvarchar](10) NULL,
	[MSCIdorSPC] [nvarchar](10) NULL,
	[CallEmlppPriority] [nvarchar](30) NULL,
	[CallerDefaultEmlppPriority] [nvarchar](30) NULL,
	[EaSubscriberInfo] [nvarchar](5) NULL,
	[SelectedCIC] [nvarchar](5) NULL,
	[optimalRoutingFlag] [nvarchar](30) NULL,
	[optimalRoutingLateForwardFlag] [nvarchar](30) NULL,
	[optimalRoutingEarlyForwardFlag] [nvarchar](30) NULL,
	[Portedflag] [nvarchar](20) NULL,
	[ChangeOfGlobalAreaID] [nvarchar](15) NULL,
	[IntermediateMCCMNC] [nvarchar](30) NULL,
	[CUGOutgoingAccessIndicator] [nvarchar](15) NULL,
	[CUGInterlockCode] [nvarchar](5) NULL,
	[CUGOutgoingAccessUsed] [nvarchar](30) NULL,
	[CUGIndex] [nvarchar](30) NULL,
	[InteractionWithIP] [nvarchar](30) NULL,
	[Hotbillingtag] [nvarchar](15) NULL,
	[VoiceIndicator] [nvarchar](25) NULL,
	[BCategory] [nvarchar](30) NULL,
	[callType] [nvarchar](15) NULL,
	[ChangeofAOCParms] [nvarchar](30) NULL,
	[ChangeofRadChan] [nvarchar](35) NULL,
	[InitialCallAttemptFlag] [nvarchar](30) NULL,
	[USSDCallbackFlag] [nvarchar](30) NULL,
	[Calledpartynumber] [nvarchar](30) NULL,
	[ISDNBearerCapability] [nvarchar](30) NULL,
	[LowLayerCompatibility] [nvarchar](30) NULL,
	[HighLayerCompatibility] [nvarchar](30) NULL,
	[BasicServiceCode] [nvarchar](30) NULL,
	[CUGIncomingAccessUsed] [nvarchar](30) NULL,
	[SMSResult] [nvarchar](10) NULL,
	[CAMELSMSInformation] [nvarchar](30) NULL,
	[SMSText] [nvarchar](200) NULL,
	[LCSClientType] [nvarchar](30) NULL,
	[LCSClientIdentity] [nvarchar](30) NULL,
	[LCSQoS] [nvarchar](30) NULL,
	[LCSPriority] [nvarchar](15) NULL,
	[MLCNumber] [nvarchar](30) NULL,
	[MeasureDuration] [nvarchar](15) NULL,
	[NotificationToMSUser] [nvarchar](60) NULL,
	[PrivacyOverride] [nvarchar](30) NULL,
	[LocationEstimate] [nvarchar](30) NULL,
	[PositioningData] [nvarchar](40) NULL,
	[LCSCause] [nvarchar](30) NULL,
	[MOLRType] [nvarchar](20) NULL,
	[lcsReferenceNumber] [nvarchar](30) NULL,
	[EMSDigits] [nvarchar](30) NULL,
	[EMSKey] [nvarchar](20) NULL,
	[SSAction] [nvarchar](20) NULL,
	[SSActiontimestamp] [nvarchar](15) NULL,
	[SSParameters] [nvarchar](30) NULL,
	[SSActionResult] [nvarchar](30) NULL,
	[USSDCodingScheme] [nvarchar](30) NULL,
	[USSDString] [nvarchar](30) NULL,
	[USSDNotifyCounter] [nvarchar](15) NULL,
	[USSDRequestCounter] [nvarchar](15) NULL,
	[Interrogationtimestamp] [nvarchar](15) NULL,
	[NumberofForwarding] [nvarchar](30) NULL,
	[interrogationResult] [nvarchar](10) NULL,
	[Equipmenttype] [nvarchar](20) NULL,
	[EquipmentId] [nvarchar](15) NULL,
	[CAMELDestinationNumber] [nvarchar](30) NULL,
	[MSCserverindication] [nvarchar](30) NULL,
	[IMEICheckEvent] [nvarchar](20) NULL,
	[EventTimeStamp] [nvarchar](15) NULL,
	[IMEIStatus] [nvarchar](30) NULL,
	[supplService] [nvarchar](30) NULL,
	[ssActionTime] [nvarchar](15) NULL,
	[basicServices] [nvarchar](30) NULL,
	[seizureTime] [nvarchar](15) NULL,
	[setupTime] [nvarchar](15) NULL,
	[alertingTime] [nvarchar](15) NULL,
	[destinationRoutingAddress] [nvarchar](30) NULL,
	[aiurRequested] [nvarchar](25) NULL,
	[DestinationCode] [int] NULL,
 CONSTRAINT [PK_MOC_1] PRIMARY KEY CLUSTERED 
(
	[callingNumber] ASC,
	[calledNumber] ASC,
	[answerTime] ASC
)WITH (PAD_INDEX  = OFF, STATISTICS_NORECOMPUTE  = OFF, IGNORE_DUP_KEY = OFF, ALLOW_ROW_LOCKS  = ON, ALLOW_PAGE_LOCKS  = ON) ON [PRIMARY]
) ON [PRIMARY]
 
/**********************************************************
Voiçi les index de la table :
**********************************************************/
CREATE NONCLUSTERED INDEX [IX_FK_MOCDestination] ON [dbo].[MOC] 
(
	[DestinationCode] ASC
)WITH (PAD_INDEX  = OFF, STATISTICS_NORECOMPUTE  = OFF, SORT_IN_TEMPDB = OFF, IGNORE_DUP_KEY = OFF, DROP_EXISTING = OFF, ONLINE = OFF, ALLOW_ROW_LOCKS  = ON, ALLOW_PAGE_LOCKS  = ON) ON [PRIMARY]
GO
 
 
CREATE NONCLUSTERED INDEX [IX_MOC_CallDuration] ON [dbo].[MOC] 
(
	[callDuration] ASC
)WITH (PAD_INDEX  = OFF, STATISTICS_NORECOMPUTE  = OFF, SORT_IN_TEMPDB = OFF, IGNORE_DUP_KEY = OFF, DROP_EXISTING = OFF, ONLINE = OFF, ALLOW_ROW_LOCKS  = ON, ALLOW_PAGE_LOCKS  = ON) ON [PRIMARY]
GO
 
 
CREATE NONCLUSTERED INDEX [IX_MOC_Location] ON [dbo].[MOC] 
(
	[location] ASC
)WITH (PAD_INDEX  = OFF, STATISTICS_NORECOMPUTE  = OFF, SORT_IN_TEMPDB = OFF, IGNORE_DUP_KEY = OFF, DROP_EXISTING = OFF, ONLINE = OFF, ALLOW_ROW_LOCKS  = ON, ALLOW_PAGE_LOCKS  = ON) ON [PRIMARY]
GO
 
 
CREATE NONCLUSTERED INDEX [IX_MOC_mscIncomingRoute] ON [dbo].[MOC] 
(
	[mscIncomingROUTE] ASC
)WITH (PAD_INDEX  = OFF, STATISTICS_NORECOMPUTE  = OFF, SORT_IN_TEMPDB = OFF, IGNORE_DUP_KEY = OFF, DROP_EXISTING = OFF, ONLINE = OFF, ALLOW_ROW_LOCKS  = ON, ALLOW_PAGE_LOCKS  = ON) ON [PRIMARY]
GO
 
 
CREATE NONCLUSTERED INDEX [IX_MOC_mscOutgoingRoute] ON [dbo].[MOC] 
(
	[mscOutgoingROUTE] ASC
)WITH (PAD_INDEX  = OFF, STATISTICS_NORECOMPUTE  = OFF, SORT_IN_TEMPDB = OFF, IGNORE_DUP_KEY = OFF, DROP_EXISTING = OFF, ONLINE = OFF, ALLOW_ROW_LOCKS  = ON, ALLOW_PAGE_LOCKS  = ON) ON [PRIMARY]
GO
 
 
CREATE NONCLUSTERED INDEX [IX_MOC_RecordParRoute] ON [dbo].[MOC] 
(
	[recordType] ASC,
	[mscOutgoingROUTE] ASC,
	[answerTime] ASC
)WITH (PAD_INDEX  = OFF, STATISTICS_NORECOMPUTE  = OFF, SORT_IN_TEMPDB = OFF, IGNORE_DUP_KEY = OFF, DROP_EXISTING = OFF, ONLINE = OFF, ALLOW_ROW_LOCKS  = ON, ALLOW_PAGE_LOCKS  = ON) ON [PRIMARY]
GO
 
 
/**********************************************************
Voiçi la structure d'une vue indexée:
**********************************************************/
Create View [dbo].[Glo] WITH SCHEMABINDING AS
			select callingnumber, callednumber, answertime, callduration
			from dbo.MOC
			where recordType = 'moCallRecord'
			and answerTime like '1103%'
			and mscOutgoingROUTE = 'Glo';
GO
 
-- et l'index associé :
CREATE UNIQUE CLUSTERED INDEX [i_abc] ON [dbo].[Glo_Benin] 
(
	[callingnumber] ASC,
	[callednumber] ASC,
	[answertime] ASC,
	[callduration] ASC
)WITH (PAD_INDEX  = OFF, STATISTICS_NORECOMPUTE  = OFF, SORT_IN_TEMPDB = OFF, IGNORE_DUP_KEY = OFF, DROP_EXISTING = OFF, ONLINE = OFF, ALLOW_ROW_LOCKS  = ON, ALLOW_PAGE_LOCKS  = ON) ON [PRIMARY]
GO

Qu'en pensez-vous ?

25/04/2011, 00h40
Invité

euh???
pourquoi tant de Nvarchar?
surtout pour des champs comme callDuration ou roamingNumber ??
C'est pour les performances ? :aie:
25/04/2011, 08h00
iberserk

OMG!!!
C'est un produit scalaire de 10 tables çà???
25/04/2011, 08h04
iberserk

Citation:

Qu'en pensez-vous?

C'est vous qui demandez:
C'est une atrocité, revoyez vos typages vous ferait économiser quelques disques dur à vos employeur!!!

Les SGBD ne sont pas un fourre tout!!!
Les dates en varchar(Nvarchar en plus complétement inutile...)!!!

Passez déjà tous les champs ne stockant que des caratères latin en varchar vous serez surpris...
Passez les entiers en INT etc...
Pensez également aux CHAR pour les colonnes de longueur fixe...
Mais surtout revoyez votre modélisation si vous le pouvez encore, il est clair que cette table peut être 'éclatée', vous allez droit dans le mur...

Pour votre vue, peut être pouvez vous filtrer également sur une date minimale (par exemple les 6 derniers mois), si vous parvenez à retrouver une date dans vos colonnes bien sur!!!

Je passe tous les commentaires déjà fait par les autres membres du forum.
Votre table ne respecte pas les règles de modélisation. Si vous pouvez il est effectivement urgent de le modifier.

Ceci dit je vais partir du principe que vous n'avez pas la maitrise de celui-ci.
Votre vue indexé ici est inutile à mon avis.

Vous pouvez tout à fait modifier votre index [IX_MOC_RecordParRoute] pour que ce dernier soit couvrant de la façon suivante :
Code:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 CREATE NONCLUSTERED INDEX [IX_MOC_RecordParRoute] ON [dbo].[MOC] ( [recordType] ASC, [mscOutgoingROUTE] ASC, [answerTime] ASC ) INCLUDE ( callingnumber, callednumber, answertime, callduration ) WITH ( PAD_INDEX = OFF, STATISTICS_NORECOMPUTE = OFF, SORT_IN_TEMPDB = OFF, IGNORE_DUP_KEY = OFF, DROP_EXISTING = OFF, ONLINE = OFF, ALLOW_ROW_LOCKS = ON, ALLOW_PAGE_LOCKS = ON ) ON [PRIMARY] GO
Ainsi cet index pourra tout à fait être utilisé par votre vue qui comprend :
Code:

1 2 3 4 5 select callingnumber, callednumber, answertime, callduration from dbo.MOC where recordType = 'moCallRecord' and answerTime like '1103%' and mscOutgoingROUTE = 'Glo';
++

Citation:

J'ai une table de base de données sql server 2008 R2

Citation:

Vous pouvez tout à fait modifier votre index [IX_MOC_RecordParRoute] pour que ce dernier soit couvrant de la façon suivante :

J'ajoute qu'avec 2008 vous pouvez aller plus loin en utilisant carremment les index filtrés:
Code:

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 CREATE NONCLUSTERED INDEX [IX_MOC_RecordParRoute] ON [dbo].[MOC] ( [recordType] ASC, [mscOutgoingROUTE] ASC, [answerTime] ASC ) INCLUDE ( callingnumber, callednumber, answertime, callduration ) WHERE recordType = 'moCallRecord' AND mscOutgoingROUTE = 'Glo'... WITH ( PAD_INDEX = OFF, STATISTICS_NORECOMPUTE = OFF, SORT_IN_TEMPDB = OFF, IGNORE_DUP_KEY = OFF, DROP_EXISTING = OFF, ONLINE = OFF, ALLOW_ROW_LOCKS = ON, ALLOW_PAGE_LOCKS = ON ) ON [PRIMARY] GO

25/04/2011, 14h14
SQLpro

C'est pas une table... C'est =un fichier Cobol. Vous en êtes resté aux années 60 de l'informatique et vous aurez beau mettre toutes les vues indexées de la terre, votre solution sera toujours pourrie !
Commencez par respecter ce qu'est un SGBD relationnel, c'est à dire fait pour gérer des relations et son des fichiers plats.
C'est toujours navrant de voir des tables ainsi faites. Sachez que dans mes audit, une table de plus de 20 colonnes est suspecte. Si elle est très utilisée, c'est plus que suspects, c'est stupide !
Commencez donc par normaliser cette chose.. Je dirais à priori que :
1) tout ce qui commence par record... devrait figurer dans une table Record
2) tout ce qui commence par Call... .. devrait figurer dans une table Call...
3) idem pour speech, CAMEL, cug, change, default, EMS, equipmnet, LCS, SS, USSD, msc, optimal.....

A +
25/04/2011, 15h44
iberserk

Citation:

C'est pas une table... C'est =un fichier Cobol. Vous en êtes resté aux années 60 de l'informatique et vous aurez beau mettre toutes les vues indexées de la terre, votre solution sera toujours pourrie !
Commencez par respecter ce qu'est un SGBD relationnel, c'est à dire fait pour gérer des relations et son des fichiers plats.
C'est toujours navrant de voir des tables ainsi faites. Sachez que dans mes audit, une table de plus de 20 colonnes est suspecte. Si elle est très utilisée, c'est plus que suspects, c'est stupide !
Commencez donc par normaliser cette chose.. Je dirais à priori que :
1) tout ce qui commence par record... devrait figurer dans une table Record
2) tout ce qui commence par Call... .. devrait figurer dans une table Call...
3) idem pour speech, CAMEL, cug, change, default, EMS, equipmnet, LCS, SS, USSD, msc, optimal.....

A +

Et encore il précise

Citation:

Voiçi la structure d'une des tables :

En général on met la plus simple en premier :-)
25/04/2011, 21h03
hunter_X

Re

Merci pour vos réponses..
La première des choses que je peux retenir de vos apports c'est que je dois revoir mon typage..Ce sera fait..même si bcp de colonnes au libellé bien explicite ne correspondent pas coté type.
En ce qui concerne la modélisation de la table, je crois avoir une explication pour sa structure. En effet, premièrement je suis entrain de mettre en oeuvre une base de données d'aide à la prise de décision et secondo la table est chargée à partir de fichiers txt qui contiennent des milliers de lignes regoupées en enregistrements pr ma table. Donc à mon humble avis je ne pense pas qu'il serait judicieux l'éclater.
Merci pour les propositions d'index couvrant et d'index filtré, elles me seront d'un grand aide.

Merci de réagir...
25/04/2011, 21h08
iberserk

Citation:

Donc à mon humble avis je ne pense pas qu'il serait judicieux l'éclater

C'est la que nos avis divergent...

Ce genre de problématique est récurrente (import de fichiers plats non normalisés ou issus de bases mal modélisées) mais l'intégration ne doit pas influencer à ce point votre propre modélisation...
25/04/2011, 21h12
SQLpro

Citation:

Envoyé par andeol

Merci pour vos réponses..
La première des choses que je peux retenir de vos apports c'est que je dois revoir mon typage..Ce sera fait..même si bcp de colonnes au libellé bien explicite ne correspondent pas coté type.

Type inapproprié = performances lamentable.
Un SGBDR a ceci de différent d'un fichier texte, c'est que les données doivent être typées !

Citation:

Envoyé par andeol

En ce qui concerne la modélisation de la table, je crois avoir une explication pour sa structure. En effet, premièrement je suis entrain de mettre en oeuvre une base de données d'aide à la prise de décision et secondo la table est chargée à partir de fichiers txt qui contiennent des milliers de lignes regoupées en enregistrements pr ma table. Donc à mon humble avis je ne pense pas qu'il serait judicieux l'éclater.

Bien que humble votre avis est des plus navrant.... Contrairement à une idée largement répandues, ce n'est pas en faisant des tables avec des dizaines de colonnes que vous améliorerez es temps de réponse, bien au contraire !

Mais vous êtes libre de ne pas suivre les avis des professionnels.

A +