Discussion :

[AntoineM_Dev]

Bonjour,

Ma question concerne l'indexation sur les colonnes calculées et leur incidence sur les performances.

Pour être plus explicite, j'ai une table qui contient une colonne de texte très longue, excédant la capacité d'indexation (limitée à 900 octets par clé), dont la structure actuelle est la suivante :

Code :

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

1
2
3
4
5
6
7
CREATE TABLE [dbo].[myTable](
    [ID] [int] IDENTITY (1, 1) PRIMARY KEY,
    [myLongText] [nvarchar](1024) NULL
) ON [PRIMARY]
GO
CREATE INDEX IX_myTable_myLongText ON dbo.myTable(myLongText)
GO

NB : Il existe déjà un index sur l'ID.

L'idée, pour éviter tout problème d'insertion, est d'indexer non pas sur la colonne elle-même, mais sur une colonne calculée dont on sait la taille limitée et inférieure à la longueur maximale de clé.
Ce qui donnerait à peu près ceci :

Code :

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

1
2
3
4
5
6
7
8
CREATE TABLE [dbo].[myTable](
    [ID] [int] IDENTITY (1, 1) PRIMARY KEY,
    [myLongText] [nvarchar](1024) NULL,
    [myComputedColumn] AS CAST(HASHBYTES('SHA1', [myLongText]) AS BIGINT) PERSISTED
) ON [PRIMARY]
GO
CREATE INDEX IX_myTable_myComputedColumn ON dbo.myTable(myComputedColumn)
GO

Ma question est la suivante : un tel index sera-t-il employé lors d'une recherche sur [myLongText] ou bien me faudra-t-il explicitement faire mes recherches en utilisant la fonction HASHBYTES ?

Merci d'avance,
Antoine

[Arkhena]

Bonjour,

L'index ne sera pas utilisé si la requête ne fait pas intervenir le CAST(HASHBYTES('SHA1', [myLongText]).

Connaissez-vous la fonctionnalité recherche full text de sql server ? http://msdn.microsoft.com/en-us/library/ms142571.aspx

Cordialement,

Arkhena

[AntoineM_Dev]

Merci de votre réponse...
Qui malheureusement confirme l'intuition que j'en avais et les quelques tests complémentaires que j'ai pu effectuer ce matin (c'est beau d'avoir, parfois, un peu de temps libre).
En fait, une simple visualisation du plan d'activité m'a permis de constater qu'il n'y avait aucun seek de fait, à moins d'employer effectivement la fonction HASHBYTES dans ma recherche.

Concernant la fonctionnalité full text de SQL SERVER, oui, j'y pensais aussi.
Mais je me suis vu répondre que ça surchargerait le serveur inutilement (l'index en question étant un des seuls de ce genre dans la base).
J'explorerai plus avant cette piste ceci dit, car j'ai des scrupules d'une part à laisser présent un index qui risque de causer des incidents sur des INSERT/UPDATE, d'autre part à laisser sans index une colonne fréquemment utilisée dans nos requêtes.

Je continue à parcourir ce forum en quête de bonnes idées et d'informations pertinentes.

Merci beaucoup.
Antoine

[Arkhena]

Qui vous a dit "ça surchargerait le serveur inutilement" ?

De deux choses l'une :
- Soit vous en avez besoin puisque c'est une colonne très utilisée dans vos requêtes et ça fait partie du boulot de SQL Server d'utiliser la RAM et la CPU à laquelle il a droit
- Soit vous n'en avez pas besoin parce que finalement les requêtes sur cette colonne sont marginales et ponctuelles et dans ce cas la question de votre index ne se pose plus

Après vous pouvez aussi proposer de revoir la modélisation de la base de données, ce qui devrait coûter encore plus cher que de rajouter un peu de RAM ou de CPU (voire simplement d'utiliser celle qui est disponible)...

Au bout d'un moment, il faut faire comprendre aux gens qu'ils ne pourront pas atteindre les 300 km/h avec une fiat panda (je précise que je n'ai rien contre cette voiturette bas de gamme fort sympathique que j'utilise quotidiennement)

Cordialement,

Arkhena

[AntoineM_Dev]

Vous prêchez un converti

[iberserk]

Bonjour,
Le fulltext semble tout indiqué si vous voulez proposer des réponses correctes (et pertinentes) à des recherche sur cette colonne.
Le fulltext est un index particulier, traité de manière tout aussi particulière par SQL SERVER (asynchrone notamment).

Qui vous a dit que cà surchargeait drastiquement le serveur?
Je mettrais ma main à couper qu'il na jamais mis en place un tel mécanisme.


NB: J'ai en revanche du mal à comprendre que la colonne à indexer soit NULLABLE?

[AntoineM_Dev]

Bonjour,

Le fulltext semble tout indiqué si vous voulez proposer des réponses correctes (et pertinentes) à des recherche sur cette colonne.
Le fulltext est un index particulier, traité de manière tout aussi particulière par SQL SERVER (asynchrone notamment).

Après interrogation personnelle et après avoir lu vos messages, comme j'indiquais précédemment, vous prêchez un converti.
Je suis curieux de ces indexes, que je n'ai jamais manipulé jusque là, et si vous avez de bonnes sources d'informations (outre ce forum, que je continue à parcourir avec avidité), elles sont les bienvenues.

Qui vous a dit que cà surchargeait drastiquement le serveur?

Peu importe. Y a-t-il un moyen pas trop complexe d'évaluer l'impact sur notre serveur SQL de la création d'un tel index ?

Je mettrais ma main à couper qu'il na jamais mis en place un tel mécanisme.

Aucune idée, mais moi non. C'est pourquoi j'ai besoin de plus d'informations pour pouvoir étayer une proposition allant dans ce sens.
Sachant qu'à la base, mon unique problématique est ce fameux index originel qui risque de crasher les INSERT/UPDATE dans la table (loi de Murphy : si ça peut crasher, ça crashera, même si ça ne s'est pas produit jusque là).

NB: J'ai en revanche du mal à comprendre que la colonne à indexer soit NULLABLE?

Il ne s'agit pas de l'index principal. Je n'ai noté ici que quelques informations pour exposer ma problématique et étayer mon propos.

Quoi qu'il en soit, je vous remercie des réponses que vous m'apportez.
Elles m'incitent à continuer à être curieux et avide d'apprendre.

Antoine

[Arkhena]

Je suis curieux de ces indexes, que je n'ai jamais manipulé jusque là, et si vous avez de bonnes sources d'informations (outre ce forum, que je continue à parcourir avec avidité), elles sont les bienvenues.

Bonjour,

Je ne peux que vous conseiller de regarder la msdn à ce sujet : http://msdn.microsoft.com/en-us/library/ms142571.aspx
(Vous pouvez changer la version de SQL Server et si vous y tenez, même si je ne vous le conseille pas, MS peut vous faire une traduction automatique en français...)

Cordialement,

Arkhena

[AntoineM_Dev]

RTFM... J'aurai dû commencer par là. Honte sur moi !

Pour la traduction en français, je n'y tiens pas. J'aime la langue de Molière, que j'essaie de ne pas trop massacrer, et les traductions automatiques sont bien trop mauvaises et sémantiquement souvent à côté.

Antoine

[SQLpro]

Pour une introduction en français, lisez l'article que j'ai écrit à ce sujet :
http://blog.developpez.com/sqlpro/p9...ext-search-no/
C'est un extrait de mon livre sur SQL : http://sqlpro.developpez.com/booksql05/

A +

[AntoineM_Dev]

Merci beaucoup.

Cette introduction est déjà bien touffue et j'ai matière à revoir le code en question.

Antoine