bonjour

j'ai une table avec un numéro de SIRET , qui est la concaténation de trois
valeurs (SIREN ,NIC, et clef)
est il possible de creer un index sur SIREN, NIC, ou sur toute fonction
deterministe basé sur les elements d'une ligne ?

évidement on pourrait retourner le probleme et stocker SIRET et NIC,
parceque f est trivialement bijective, mais même bijective, et pire encore
si non, difficile d'avoir toujours ce genre de solutions...

je suis en SQL Server 2005 (Express)

merci d'avance pour vos lumieres

Pas clair. Généralement on sépare les éléments constitutifs chacun dans leur
colonne et on index ensuite les colonnes qui nous intéressent
(éventuellement un contournement serait sans doute de créer un champ calculé
et de l'indexer).

Je crois comprendre que le but est d'indexer sur une partie d'un champ ?

--
Patrice

"Ambassadeur kosh" <kosh.naranek@babylon5.net> a écrit dans le message de
news: twR_i.2$xG2.20@nntpserver.swip.net...
> bonjour
>
> j'ai une table avec un numéro de SIRET , qui est la concaténation de trois
> valeurs (SIREN ,NIC, et clef)
> est il possible de creer un index sur SIREN, NIC, ou sur toute fonction
> deterministe basé sur les elements d'une ligne ?
>
> évidement on pourrait retourner le probleme et stocker SIRET et NIC,
> parceque f est trivialement bijective, mais même bijective, et pire encore
> si non, difficile d'avoir toujours ce genre de solutions...
>
> je suis en SQL Server 2005 (Express)
>
> merci d'avance pour vos lumieres
>

Ambassadeur kosh a écrit :
> bonjour
>
> j'ai une table avec un numéro de SIRET , qui est la concaténation de trois
> valeurs (SIREN ,NIC, et clef)
> est il possible de creer un index sur SIREN, NIC, ou sur toute fonction
> deterministe basé sur les elements d'une ligne ?
>
> évidement on pourrait retourner le probleme et stocker SIRET et NIC,
> parceque f est trivialement bijective, mais même bijective, et pire encore
> si non, difficile d'avoir toujours ce genre de solutions...
>
> je suis en SQL Server 2005 (Express)
>
> merci d'avance pour vos lumieres
>

vous pouvez faire :
1) une indexation multicolonne
2) une colonne calculée indexée
3) une vue indexée.

précisez cepandant votre modèle, ou poura mieux vous aider !

A +

>


--
Frédéric BROUARD, MVP SQL Server, expert bases de données et langage SQL
Le site sur le langage SQL et les SGBDR : http://sqlpro.developpez.com
Audit, conseil, expertise, formation, modélisation, tuning, optimisation
*********************** http://www.sqlspot.com *************************

merci à tous les deux pour vos réponses.

le cas qu'on a , ici, c'est Siren, Siret, et Nic. ce qui lui est spécifique,
c'est qu'on fait des recherches sur Siren et que Siret = Concat(Siren,Nic),
et donc que l'ordre sur les chaines est facile à utiliser pour solutionner
le truc (sans compter la bijectivité).

d'une façon plus générale, je me demandais si pour indexer, on pouvait
éviter le stockage. comme on le ferait pour une hashtable en fournissant une
fonction de hashage, au lieu de fournir le nom d'un champ qui contient le
résultat de la fonction de hashage.

l'idée, c'est indexons, mais sans stocker, pour gagner de la place...

peut être que c'est une view avec une colone expression et qu'on peut
indexer cette colone dans la vue la solution, je sais pas... je cherche un
concept qui se rapproche de ça.

voila donc, reconsituer une donnée à partir d'une clef de hashage, vous
voyez bien que c'est pas trop possible, rapport à la bijectivité ou à la
complexité de l'inversion de f...

maintenant si vous me dites que la solution, c'est stocker la clef de
recherche, basta, rapport aux perfs, aux possibilités, à la capacité à
expliquer les résultats d'une appli etc etc, eh ben on va stocker la clef de
recherche, et basta...


--
Frédéric DIDIER

Ambassadeur kosh a écrit :
> merci à tous les deux pour vos réponses.
>
> le cas qu'on a , ici, c'est Siren, Siret, et Nic. ce qui lui est spécifique,
> c'est qu'on fait des recherches sur Siren et que Siret = Concat(Siren,Nic),
> et donc que l'ordre sur les chaines est facile à utiliser pour solutionner
> le truc (sans compter la bijectivité).
>
> d'une façon plus générale, je me demandais si pour indexer, on pouvait
> éviter le stockage. comme on le ferait pour une hashtable en fournissant une
> fonction de hashage, au lieu de fournir le nom d'un champ qui contient le
> résultat de la fonction de hashage.
>
> l'idée, c'est indexons, mais sans stocker, pour gagner de la place...

un index sur une colonne calculée créera l'index sans les données.
Vous créez les colonnes SIREN et NIC et une colonne SIRET AS SIREN + NIC
Puis vous posez un index sur SIRET. C'est tout.

>
> peut être que c'est une view avec une colone expression et qu'on peut
> indexer cette colone dans la vue la solution, je sais pas... je cherche un
> concept qui se rapproche de ça.
>
> voila donc, reconsituer une donnée à partir d'une clef de hashage, vous
> voyez bien que c'est pas trop possible, rapport à la bijectivité ou à la
> complexité de l'inversion de f...
>
> maintenant si vous me dites que la solution, c'est stocker la clef de
> recherche, basta, rapport aux perfs, aux possibilités, à la capacité à
> expliquer les résultats d'une appli etc etc, eh ben on va stocker la clef de
> recherche, et basta...
>
>
> --
> Frédéric DIDIER
>
>

A +


--
Frédéric BROUARD, MVP SQL Server, expert bases de données et langage SQL
Le site sur le langage SQL et les SGBDR : http://sqlpro.developpez.com
Audit, conseil, expertise, formation, modélisation, tuning, optimisation
*********************** http://www.sqlspot.com *************************

> un index sur une colonne calculée créera l'index sans les données.
> Vous créez les colonnes SIREN et NIC et une colonne SIRET AS SIREN + NIC
> Puis vous posez un index sur SIRET. C'est tout.

ok, c'est aussi simple que ça...
curiosité, c'est possible aussi sous SqlServer 2000 ?

en tout cas, merci pour ce coup de pouce.

--
Frédéric DIDIER

Ambassadeur kosh a écrit :
>> un index sur une colonne calculée créera l'index sans les données.
>> Vous créez les colonnes SIREN et NIC et une colonne SIRET AS SIREN + NIC
>> Puis vous posez un index sur SIRET. C'est tout.
>
> ok, c'est aussi simple que ça...
> curiosité, c'est possible aussi sous SqlServer 2000 ?

oui.

>
> en tout cas, merci pour ce coup de pouce.
>

pas de quoi !

> --
> Frédéric DIDIER
>
>


--
Frédéric BROUARD, MVP SQL Server, expert bases de données et langage SQL
Le site sur le langage SQL et les SGBDR : http://sqlpro.developpez.com
Audit, conseil, expertise, formation, modélisation, tuning, optimisation
*********************** http://www.sqlspot.com *************************