IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)
Navigation

Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter

Affichage des résultats du sondage: Préférez-vs mettre les index d'une table au niveau d'une vue indexée ?

Votants
1. Vous ne pouvez pas participer à ce sondage.
  • Oui..indexer uniquement la table

    0 0%
  • Non...Indexer uniquement la vue

    0 0%
  • Les deux

    1 100,00%
Sondage à choix multiple
Développement SQL Server Discussion :

Performance d'une vue indexée


Sujet :

Développement SQL Server

  1. #1
    Membre averti
    Inscrit en
    Septembre 2008
    Messages
    28
    Détails du profil
    Informations forums :
    Inscription : Septembre 2008
    Messages : 28
    Par défaut 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

  2. #2
    Expert confirmé
    Avatar de mikedavem
    Homme Profil pro
    Administrateur de base de données
    Inscrit en
    Août 2005
    Messages
    5 450
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 47
    Localisation : France, Ain (Rhône Alpes)

    Informations professionnelles :
    Activité : Administrateur de base de données
    Secteur : Distribution

    Informations forums :
    Inscription : Août 2005
    Messages : 5 450
    Par défaut
    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.

    ++

  3. #3
    Membre Expert Avatar de iberserk
    Homme Profil pro
    Architecte de base de données
    Inscrit en
    Novembre 2004
    Messages
    1 795
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 43
    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 795
    Par défaut
    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/

  4. #4
    Membre Expert

    Homme Profil pro
    Administrateur de base de données
    Inscrit en
    Août 2007
    Messages
    1 216
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 42
    Localisation : Suisse

    Informations professionnelles :
    Activité : Administrateur de base de données
    Secteur : Industrie Pharmaceutique

    Informations forums :
    Inscription : Août 2007
    Messages : 1 216
    Par défaut
    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.

  5. #5
    Membre Expert Avatar de iberserk
    Homme Profil pro
    Architecte de base de données
    Inscrit en
    Novembre 2004
    Messages
    1 795
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 43
    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 795
    Par défaut
    demandez vous si cette table n'est pas une bonne candidate au partitionning

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

  6. #6
    Membre averti
    Inscrit en
    Septembre 2008
    Messages
    28
    Détails du profil
    Informations forums :
    Inscription : Septembre 2008
    Messages : 28
    Par défaut Re
    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 ?

  7. #7
    Invité
    Invité(e)
    Par défaut
    euh???
    pourquoi tant de Nvarchar?
    surtout pour des champs comme callDuration ou roamingNumber ??
    C'est pour les performances ?

  8. #8
    Membre Expert Avatar de iberserk
    Homme Profil pro
    Architecte de base de données
    Inscrit en
    Novembre 2004
    Messages
    1 795
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 43
    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 795
    Par défaut
    OMG!!!
    C'est un produit scalaire de 10 tables çà???

  9. #9
    Membre Expert Avatar de iberserk
    Homme Profil pro
    Architecte de base de données
    Inscrit en
    Novembre 2004
    Messages
    1 795
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 43
    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 795
    Par défaut
    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!!!

  10. #10
    Expert confirmé
    Avatar de mikedavem
    Homme Profil pro
    Administrateur de base de données
    Inscrit en
    Août 2005
    Messages
    5 450
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 47
    Localisation : France, Ain (Rhône Alpes)

    Informations professionnelles :
    Activité : Administrateur de base de données
    Secteur : Distribution

    Informations forums :
    Inscription : Août 2005
    Messages : 5 450
    Par défaut
    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';
    ++

  11. #11
    Membre Expert Avatar de iberserk
    Homme Profil pro
    Architecte de base de données
    Inscrit en
    Novembre 2004
    Messages
    1 795
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 43
    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 795
    Par défaut
    J'ai une table de base de données sql server 2008 R2
    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

  12. #12
    Rédacteur

    Avatar de SQLpro
    Homme Profil pro
    Expert bases de données / SQL / MS SQL Server / Postgresql
    Inscrit en
    Mai 2002
    Messages
    22 021
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Var (Provence Alpes Côte d'Azur)

    Informations professionnelles :
    Activité : Expert bases de données / SQL / MS SQL Server / Postgresql
    Secteur : Conseil

    Informations forums :
    Inscription : Mai 2002
    Messages : 22 021
    Billets dans le blog
    6
    Par défaut
    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
    Le site sur les SGBD relationnels et le langage SQL: http://sqlpro.developpez.com/
    Blog SQL, SQL Server, SGBDR : http://blog.developpez.com/sqlpro
    Expert Microsoft SQL Server - M.V.P. (Most valuable Professional) MS Corp.
    Entreprise SQL SPOT : modélisation, conseils, audit, optimisation, formation...
    * * * * * Expertise SQL Server : http://mssqlserver.fr/ * * * * *

  13. #13
    Membre Expert Avatar de iberserk
    Homme Profil pro
    Architecte de base de données
    Inscrit en
    Novembre 2004
    Messages
    1 795
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 43
    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 795
    Par défaut
    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
    Voiçi la structure d'une des tables :
    En général on met la plus simple en premier :-)

  14. #14
    Membre averti
    Inscrit en
    Septembre 2008
    Messages
    28
    Détails du profil
    Informations forums :
    Inscription : Septembre 2008
    Messages : 28
    Par défaut 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...

  15. #15
    Membre Expert Avatar de iberserk
    Homme Profil pro
    Architecte de base de données
    Inscrit en
    Novembre 2004
    Messages
    1 795
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 43
    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 795
    Par défaut
    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...

  16. #16
    Rédacteur

    Avatar de SQLpro
    Homme Profil pro
    Expert bases de données / SQL / MS SQL Server / Postgresql
    Inscrit en
    Mai 2002
    Messages
    22 021
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Var (Provence Alpes Côte d'Azur)

    Informations professionnelles :
    Activité : Expert bases de données / SQL / MS SQL Server / Postgresql
    Secteur : Conseil

    Informations forums :
    Inscription : Mai 2002
    Messages : 22 021
    Billets dans le blog
    6
    Par défaut
    Citation Envoyé par andeol Voir le message
    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 Voir le message
    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 +
    Frédéric Brouard - SQLpro - ARCHITECTE DE DONNÉES - expert SGBDR et langage SQL
    Le site sur les SGBD relationnels et le langage SQL: http://sqlpro.developpez.com/
    Blog SQL, SQL Server, SGBDR : http://blog.developpez.com/sqlpro
    Expert Microsoft SQL Server - M.V.P. (Most valuable Professional) MS Corp.
    Entreprise SQL SPOT : modélisation, conseils, audit, optimisation, formation...
    * * * * * Expertise SQL Server : http://mssqlserver.fr/ * * * * *

Discussions similaires

  1. Performances d'une vue ?
    Par khayyam90 dans le forum Requêtes
    Réponses: 1
    Dernier message: 23/01/2010, 20h43
  2. Impossible de créer une vue indexée
    Par cmako dans le forum Développement
    Réponses: 2
    Dernier message: 18/09/2009, 12h05
  3. Probleme de performance sur une vue
    Par nomissamoht dans le forum Oracle
    Réponses: 1
    Dernier message: 06/03/2009, 15h51
  4. Problème de performance d'une vue
    Par Christophe Charron dans le forum Requêtes
    Réponses: 0
    Dernier message: 31/07/2008, 15h21
  5. [Debutant]Problème de création d'une vue indexée
    Par Le Pharaon dans le forum MS SQL Server
    Réponses: 2
    Dernier message: 15/11/2006, 13h50

Partager

Partager
  • Envoyer la discussion sur Viadeo
  • Envoyer la discussion sur Twitter
  • Envoyer la discussion sur Google
  • Envoyer la discussion sur Facebook
  • Envoyer la discussion sur Digg
  • Envoyer la discussion sur Delicious
  • Envoyer la discussion sur MySpace
  • Envoyer la discussion sur Yahoo