SQL CE - Index sur char[6] ou bigint

Bonjour,
Ma requête ne concerne pas exactement sql server, mais plutôt SQL compact, mais il n'y a pas de forum dédie :(
J'ai un numéro à 11 chiffres à stocker en tant qu'index. Sachant qu'il s'agit d'un travail sur PDA, et que les recherches sont assez fréquentes, j'aimerais savoir comment optimiser au maximum...
Je peux donc soit stocker le nombre dans un biging (donc 8 octets) soit le stocker dans un char[6] ce qui économiserait 2 octets.
Je me demandais juste s'il y avait des optimisations qui au final feraient qu'il serait aussi efficace d'utiliser un bigint que 6 octets pour indexer et rechercher.
Niveau quantité de données à rechercher, il doit y avoir cet identifiant + éventuellement 1 ou 2 booleans si les perfs ne sont pas trop impactées. Avec un nombre d'entrées d'environ 10-15000.
Merci d'avance pour les conseils ;)

Citation:

---

Avec un nombre d'entrées d'environ 10-15000.

---

Et combien de sorties? C'est important:ccool:

Comment stockez vous un nombre à 11 chiffres dans un char(6)???

Cela dit 10000/15000 lignes dans votre table c'est vraiment très faible.

Partez sur du BIGINT.

Bonjour,

Citation:

---

Comment stockez vous un nombre à 11 chiffres dans un char(6)???

---

Cela m'a choqué aussi ... Stockeriez des nombres en hexadécimal dans une colonne char ?

En revanche pour le bigint, je ne suis pas tout à faire d'accord : probablement qu'un int (4 octets, 5 milliards de possibilités) suffirait amplement.

D'autre part retenez que les jointures sur du CHAR, c'est vraiment pas terrible.
Pour en avoir une meilleure idée, lisez ce sujet

@++ ;)

Citation:

---

En revanche pour le bigint, je ne suis pas tout à faire d'accord : probablement qu'un int (4 octets, 5 milliards de possibilités) suffirait amplement.

---

A oui ??? :ccool:

Code:

---

1 2 3 4

SELECT CAST (99999999999 AS INTEGER) Msg*8115, Niveau*16, État*2, Ligne*1 Une erreur de dépassement arithmétique s'est produite lors de la conversion de expression en type de données int.

---

Bonjour

Citation:

---

Envoyé par jo_dalton

J'ai un numéro à 11 chiffres à stocker en tant qu'index.

---

C'est à dire ?
Avez vous l'intention d'utiliser un code (code article, code client ou autre sur 11 chiffres) comme clef primaire ? si c'est le cas, c'est une mauvaise idée.

pouvez vous développer un peu la structure de votre table ?

@iberserk : OK, je prend zéro ... j'ai zappé :(

@++ ;)

Pas plus de commentaires sur la taille de stockage ;) Si j'avais pu le stocker dans du int ça m'aurait bien arrangé aussi :)

Par contre 10/15k dans une table c'est très faible peut être pour un PC, mais pour un pocketPC/SqlCe ça n'est pas vraiment négligeable... D'où le besoin d'un piti peu d'optimisation

Pour ce qui est des jointures, je ne pense pas en faire - à priori ça n'est que pour de la recherche, j'utilise un autre champ pour la jointure si nécessaire.

D'où ma question, à savoir s'il était en général plus optimisé de stocker dans 6 octets char ou 8 du bigint pour une recherche (sachant qu'il peut y avoir des optimisations pour les traitements 32bits & toussa...)

Citation:

---

Envoyé par aieeeuuuuu

Bonjour


C'est à dire ?
Avez vous l'intention d'utiliser un code (code article, code client ou autre sur 11 chiffres) comme clef primaire ? si c'est le cas, c'est une mauvaise idée.

pouvez vous développer un peu la structure de votre table ?

---

Oui, c'est bien pour l'utiliser comme clef primaire.
C'est un numéro qui vient d'un code barre ou d'un RFID, et les 11 chiffres ne sont pas négociables :)
La table me permet d'obtenir à la suite d'un scan un identifiant de travail plus simple pour aller travailler dans d'autres tables.

L'objectif est de récupérer l'identifiant (int) et le nom de la table dans un champ qui seront utilisés un peu plus tard. Mais comme il est possible de scanner plusieurs fois en un temps assez court, il faut que le programme ait le temps de trouver l'information pour passer au scan suivant.

Citation:

---

Envoyé par jo_dalton

C'est un numéro qui vient d'un code barre ou d'un RFID, et les 11 chiffres ne sont pas négociables :)

---

Alors raison de plus. je pense que vous devriez utiliser un identifiant en INT, plutôt que d'utiliser directement le code barre comme identifiant.


par ailleurs, j'aimerai aussi connaitre la réponse à la pertinente question d'Ibersek :

Citation:

---

Comment stockez vous un nombre à 11 chiffres dans un char(6)???

---

Enfin, l'une de vos phrase m'interpelle :

Citation:

---

L'objectif est de récupérer l'identifiant (int) et le nom de la table dans un champ

---

pourquoi le nom de table ? La aussi j'ai l'impression que votre modèle est perfectible. Vous voulez récupérer à partir du code barre un nom de table pour lancer une requête sur cette table ?

Citation:

---

Alors raison de plus. je pense que vous devriez utiliser un identifiant en INT

---

Na, bigint, j'ai fait la même erreur : il soit stocker 11 chiffres.

Un truc par contre : les chiffres peuvent-ils commencer par un zéro ?
Parce que si c'est le cas, vous le perdrez au stockage si vous utilisez un entier ...

@++ ;)

Citation:

---

Envoyé par aieeeuuuuu

par ailleurs, j'aimerai aussi connaitre la réponse à la pertinente question d'Ibersek

---

De la même façon qu'il est stocké dans un int ou un bigint, ce serait juste un bigint raccourci :) (c'est rapide à faire, et si ça fait gagner 3 secondes pendant une recherche, ça me va très bien!!)

[quote=aieeeuuuuu;6017491]Alors raison de plus. je pense que vous devriez utiliser un identifiant en INT, plutôt que d'utiliser directement le code barre comme identifiant.[QUOTE]
Je ne l'utilise pas comme identifiant, mais comme index d'une table qui va me dire à quel type il correspond et l'identifiant int correspondant à une table qui devrait être plus courte

Citation:

---

Envoyé par aieeeuuuuu

pourquoi le nom de table ? La aussi j'ai l'impression que votre modèle est perfectible. Vous voulez récupérer à partir du code barre un nom de table pour lancer une requête sur cette table ?

---

Le modèle est probablement perfectible, mais fonctionne très bien pour l'instant ;)
Jusqu'à présent il n'y avait pas de lecteur numérique, et on choisissait la table avant de faire la requête. Avec le lecteur plutôt que de choisir la table manuellement, chaque entrée étant unique, je peux la déduire du numéro scanné. Le lecteur me retourne une chaine de caractères de 11 chiffres que je traduis en numérique.

La saisie manuelle est toujours possible, donc je n'ai pas interêt à changer l'ancien modèle qui se base sur 3 tables différentes.

En gros j'aurai:
1 table contenant le code scan
avec le code, le type d'article et l'id article

3 tables contenant différents types d' "articles"

Dans la mesure où au moment du scann je n'ai pas besoin directement de l'information liée à l'article, mais uniquement son existance, il n'y a pas de soucis.
Cette table n'est interrogée QUE lors d'une lecture numérique, pas lors du fonctionnement du programme.

Merci pour vos réponses :)

Citation:

---

Envoyé par elsuket

Un truc par contre : les chiffres peuvent-ils commencer par un zéro ?
Parce que si c'est le cas, vous le perdrez au stockage si vous utilisez un entier ...

---

Oui, mais c'est pas vraiment un problème puisque ils sont uniques et qu'ils ont toujours le format 11 chiffres, donc si je veux l'afficher un PaddingLeft de 0 et c'est bon :)


Et donc pour la question initiale, qui est de l'optimisation d'indexage? Plutôt bigint ou char[6] ?

Citation:

---

Envoyé par jo_dalton

De la même façon qu'il est stocké dans un int ou un bigint, ce serait juste un bigint raccourci :)

---

:koi:

Reprennons :

Un CHAR(6) permet de stocker 6 caractères...
même en tassant bien, vous aurez du mal à y en mettre 11.

Il y aurait certes moyen de convertir votre nombre base 10 en base 256 (et dans ce cas il me semble qu'un CHAR(5) suffirait) mais ça me semble tordu...:aie:

CHAR(6)...

à moins que vous ne comptiez découper votre nombre de 11 chiffres en 5 nombre de 2 chiffres plus un nombre de 1 chiffre, et stocker leur correspondance ASCII ???

Dans ce cas je comprend mieux le CHAR(6) mais... ça me semble tout aussi tordu :aie:

Notez tout de même que j'ai déjà vu plein d'idées tordues fonctionner à merveille ! :lol:

Citation:

---

Envoyé par aieeeuuuuu

CHAR(6)...

à moins que vous ne comptiez découper votre nombre de 11 chiffres en 5 nombre de 2 chiffres plus un nombre de 1 chiffre, et stocker leur correspondance ASCII ???

Dans ce cas je comprend mieux le CHAR(6) mais... ça me semble tout aussi tordu :aie:

Notez tout de même que j'ai déjà vu plein d'idées tordues fonctionner à merveille ! :lol:

---

Et bien heu... en fait je ne vois pas trop ce qu'il y a de tordu :p juste un peu radin, mais bon: char[6] => 2^(6*8) possibilités ?
(sachant que int ~ char[4] ou bigint ~ char[8] si je ne me trompe pas ;) )
Je ne veux pas stocker les caractères des nombres mais bien leur valeur!

Enfin de ttes façons je suis parti sur du bigint, si ça rame je verrai si je modifie :D

Citation:

---

Et bien heu... en fait je ne vois pas trop ce qu'il y a de tordu :p juste un peu radin, mais bon: char[6] => 2^(6*8) possibilités ?
(sachant que int ~ char[4] ou bigint ~ char[8] si je ne me trompe pas )
Je ne veux pas stocker les caractères des nombres mais bien leur valeur!

---

Moi yen a plus rien comprendre :-)

montrer un exemple de votre "entier à 11 chiffres qui est en en fait un index stocké sur 6 caractères offrant des possibilité 2^(6*8)" :mouarf:

Citation:

---

sachant que int ~ char[4] ou bigint ~ char[8] si je ne me trompe pas

---

Vous confondez longueur de stockage et type de stockage...


Un INT code des valeurs en binaire en base 2 sur 4 octets...
Un CHAR[6] stocke seulement six caractères, chaque caractère sur un octets...

Donc vous ne pouvez stocker 2364323 dans un char[6]... mais dans un INT oui... Compris?

Citation:

---

Envoyé par jo_dalton

3 tables contenant différents types d' "articles"

---

Quelle horreur !
Et alors quand vous avez un nouveau type d'article, vous ajoutez une table, et vous modifiez le code de votre application pour qu'elle prenne en compte cette nouvelle table ? :mrgreen:
Quelle flexibilité !

Citation:

---

Envoyé par aieeeuuuuu

même en tassant bien, vous aurez du mal à y en mettre 11.

---

:ccool: :mouarf:

Citation:

---

Envoyé par iberserk

Moi yen a plus rien comprendre :-)

---

Rassures-toi t'es pas tout seul !
Pourquoi faire simple quand on peut faire compliqué, hein ? :zoubi:

Passez en bigint, "et pis c'est tout" ;)

@++ ;)

En fait je pense que notre ami (..) veut lui même convertir ses entiers à 11 chiffres en binaire, il calcul donc qu'il n'aura besoin que de 6 octets pour gérer tout ses nombres...


Mais vous faites erreur car la représentation sur 6 octets en binaire donnera quelque chose comme çà:

1010 1010 1111 1111 1010 1010 soit 30 caractères... donc votre CHAR[6] ne sers strictement à rien ici§ les entiers n'ont pas été inventés pour rien!!!

Manifestement vous avez des lacunes sur les typages de base des données...

Une introduction ici

@++ ;)

1. Je ne pense pas avoir parlé de caractères pour mon numéro, mais de chiffres

Citation:

---

En fait je pense que notre ami (..) veut lui même convertir ses entiers à 11 chiffres en binaire, il calcul donc qu'il n'aura besoin que de 6 octets pour gérer tout ses nombres...

---

OUI

Citation:

---

1010 1010 1111 1111 1010 1010 soit 30 caractères... donc votre CHAR[6] ne sers strictement à rien ici

---

Comme je l'ai dit: pas 11 caractères, mais 11 chiffres, donc un nombre ;)
C'est à dire seulement les 6 derniers octets d'un UInt64.... les 2 premiers étant des 0.

Citation:

---

Manifestement vous avez des lacunes sur les typages de base des données...

---

Peut être, mais pas pour ce cas là ;)

Citation:

---

Quelle horreur !
Et alors quand vous avez un nouveau type d'article, vous ajoutez une table, et vous modifiez le code de votre application pour qu'elle prenne en compte cette nouvelle table ?
Quelle flexibilité !

---

En fait il s'agit d'animaux ^^ Père/Mère/Enfant, et ça fait quelques temps qu'on a pas ajouté de nouvelle catégorie pour ça :) Et sachant qu'il y a des informations complètement differentes pour chacun, impossible de les stocker dans la même table!

Citation:

---

Pourquoi faire simple quand on peut faire compliqué, hein ?

Passez en bigint, "et pis c'est tout"

---

Dans le doute c'est fait ^^


Bon c'est pas grave, j'ai juste eu qqes soucis à faire passer ma problématique apparemment. :aie: :mouarf:

Merci qd même pour votre aide! :ccool: La réactivité est appréciable!

Code:

---

Comme je l'ai dit: pas 11 caractères, mais 11 chiffres, donc un nombre

---

Je maintiens...
Excusez moi mais un nombre à 11 chiffres c'est par exemple: 12345678901 on est daccord?

Vous aurez du mal à convertir çà en binaire avec un char[6]:mouarf:

Donc le tuto de elsuket ne devrait pas vous faire du mal...