Performance d'une vue indexée

hunter_X · 23/04/2011, 23h06

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

mikedavem · 24/04/2011, 08h01

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.

++

iberserk · 24/04/2011, 08h54

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/

Ptit_Dje · 24/04/2011, 10h27

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.

iberserk · 24/04/2011, 12h55

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!

hunter_X · 24/04/2011, 22h58

Merci à tous pour vos apports..

Voiçi la structure d'une des tables :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

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 ?

7gyY9w1ZY6ySRgPeaefZ · 25/04/2011, 00h40

euh???
pourquoi tant de Nvarchar?
surtout pour des champs comme callDuration ou roamingNumber ??
C'est pour les performances ?

iberserk · 25/04/2011, 08h00

OMG!!!
C'est un produit scalaire de 10 tables çà???

iberserk · 25/04/2011, 08h04

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!!!

mikedavem · 25/04/2011, 10h44

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 :

Sélectionner tout - Visualiser dans une fenêtre à part

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 :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
SELECT callingnumber, callednumber, answertime, callduration
FROM dbo.MOC
WHERE recordType = 'moCallRecord'
AND answerTime LIKE '1103%'
AND mscOutgoingROUTE = 'Glo';

++

iberserk · 25/04/2011, 13h16

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 :

Sélectionner tout - Visualiser dans une fenêtre à part

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

SQLpro · 25/04/2011, 14h14

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 +

iberserk · 25/04/2011, 15h44

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 :-)

hunter_X · 25/04/2011, 21h03

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...

iberserk · 25/04/2011, 21h08

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...

SQLpro · 25/04/2011, 21h12

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 +

23/04/2011, 23h06	#1
hunter_X Invité de passage viper viper Inscription : septembre 2008 Messages : 25 Détails du profil Informations personnelles : Nom : viper viper Informations forums : Inscription : septembre 2008 Messages : 25 Points : 2 Points : 2	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
	00

24/04/2011, 08h01	#2
mikedavem Responsable SQL Server David BARBARIN Expert SQL Server Inscription : août 2005 Messages : 3 723 Détails du profil Informations personnelles : Nom : David BARBARIN Localisation : France, Haute Savoie (Rhône Alpes) Informations professionnelles : Activité : Expert SQL Server Secteur : Conseil Informations forums : Inscription : août 2005 Messages : 3 723 Points : 6 844 Points : 6 844	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. ++ __________________ Blog \| Articles SQL Server \| TSQL Challenges \| English blog
	00

24/04/2011, 08h54	#3
iberserk Membre Expert Bruno IGNACE Architecte de base de données Inscription : novembre 2004 Messages : 1 299 Détails du profil Informations personnelles : Nom : Bruno IGNACE Âge : 30 Localisation : France, Gironde (Aquitaine) Informations professionnelles : Activité : Architecte de base de données Secteur : High Tech - Éditeur de logiciels Informations forums : Inscription : novembre 2004 Messages : 1 299 Points : 2 282 Points : 2 282	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/ __________________ Prendre conscience, c'est transformer le voile qui recouvre la lumière en miroir.
	00

25/04/2011, 00h40	#7
7gyY9w1ZY6ySRgPeaefZ Expert Confirmé dba Inscription : juillet 2007 Messages : 2 520 Détails du profil Informations personnelles : Sexe : Localisation : Canada Informations professionnelles : Activité : dba Informations forums : Inscription : juillet 2007 Messages : 2 520 Points : 3 967 Points : 3 967	euh??? pourquoi tant de Nvarchar? surtout pour des champs comme callDuration ou roamingNumber ?? C'est pour les performances ? __________________ les règles du forum - mode d'emploi du forum Aucun navigateur ne propose d'extension boule-de-cristal : postez votre code et vos messages d'erreurs. (Rappel : "ça ne marche pas" n'est pas un message d'erreur) JE NE RÉPONDS PAS aux questions techniques par message privé. Écrire en français sur un forum est une marque minimale de respect.
	00

25/04/2011, 08h00	#8
iberserk Membre Expert Bruno IGNACE Architecte de base de données Inscription : novembre 2004 Messages : 1 299 Détails du profil Informations personnelles : Nom : Bruno IGNACE Âge : 30 Localisation : France, Gironde (Aquitaine) Informations professionnelles : Activité : Architecte de base de données Secteur : High Tech - Éditeur de logiciels Informations forums : Inscription : novembre 2004 Messages : 1 299 Points : 2 282 Points : 2 282	OMG!!! C'est un produit scalaire de 10 tables çà??? __________________ Prendre conscience, c'est transformer le voile qui recouvre la lumière en miroir.
	10

24/04/2011, 10h27	#4
Ptit_Dje Modérateur Administrateur de base de données Inscription : août 2007 Messages : 1 158 Détails du profil Informations personnelles : Sexe : Âge : 28 Localisation : Belgique Informations professionnelles : Activité : Administrateur de base de données Secteur : Industrie Pharmaceutique Informations forums : Inscription : août 2007 Messages : 1 158 Points : 1 617 Points : 1 617	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.
	00

25/04/2011, 14h14	#12
SQLpro Rédacteur/Modérateur Frédéric BROUARD Expert SGBDR & SQL Inscription : mai 2002 Messages : 10 953 Détails du profil Informations personnelles : Nom : Frédéric BROUARD Localisation : France Informations professionnelles : Activité : Expert SGBDR & SQL Secteur : Conseil Informations forums : Inscription : mai 2002 Messages : 10 953 Points : 17 773 Points : 17 773	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 + __________________ Frédéric Brouard - SQLpro - ARCHITECTE DE DONNÉES - expert SGBDR et langage SQL Site sur les SGBD relationnels et le langage SQL: http://sqlpro.developpez.com/ *Expert Microsoft SQL Server - M.V.P. (Most valuable Professional) MS Corp.* Blog SQL, SQL Server, modélisation données : http://blog.developpez.com/sqlpro http://www.sqlspot.com : modélisation, conseils, audit, optimisation, formation * * * * * Enseignant CNAM PACA - ISEN Toulon - CESI Aix en Provence * * * * *
	10

25/04/2011, 21h03	#14
hunter_X Invité de passage viper viper Inscription : septembre 2008 Messages : 25 Détails du profil Informations personnelles : Nom : viper viper Informations forums : Inscription : septembre 2008 Messages : 25 Points : 2 Points : 2	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...
	01

Outils de la discussion
Afficher une version imprimable Envoyer un lien vers cette page par email