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

Citation:

---

Envoyé par iberserk

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

---

Je maintiens... char[6] = 2^(6*8) = 2^48 = 281 474 976 710 656 possibilités d'après la calculatrice windows ;) soit de quoi stocker 14 chiffres + 1 bit libre :)
(en se basant comme je le disais plus haut sur 6 octets du int64, je sais ça complique... Mais étant donné que j'ai un framework d'accès aux données ça ne change que qqes lignes...)
Le tuto est intéressant, mais je sais déjà tout ça ;)

La base n'est pas du SQL Serveur, mais du compact SQL, sur un mobile qui a 3 ans, donc peu de puissance! D'où mon interrogation pour les 2 octets.. (du point de vue stockage & recherche!) N'étant pas certain d'obtenir un résultatintéressant niveau recherche (et la remarque plus haut du fait que les jointures du char était plutôt mauvaise, pas d'actualité, mais on ne sais jamais...), je suis parti sur du bigint

Citation:

---

char[6] = 2^(6*8) = 2^48 = 281 474 976 710 656

---

Complétement faux :(

Char 6 stocke 6 caractères... chacun sur 1 octet.... vous ne pouvez pas stocker un octet 'binaire' sur un CHAR[1]

Ai-je été clair?:cry:

Citation:

---

Envoyé par jo_dalton

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!

---

Ben comme iberserk, je maintiens : dans ce cas il vous faut une table personne, qui stocke les caractéristiques communes à ceux-ci, et des tables qui stockent la valeur de clé primaire avec les caractéristiques spécifiques à chacun des types d'"animaux", et qui référencent la table personne.
On appelle cela la spécialisation.

@++ ;)

Pour iberserk: En effet, le type adéquate pour ce que je voulais potentiellement faire est binary, et non char...

Citation:

---

Envoyé par elsuket

Ben comme iberserk, je maintiens : dans ce cas il vous faut une table personne, qui stocke les caractéristiques communes à ceux-ci, et des tables qui stockent la valeur de clé primaire avec les caractéristiques spécifiques à chacun des types d'"animaux", et qui référencent la table personne.
On appelle cela la spécialisation.

@++ ;)

---

Merci,
Celle-ci existe en effet depuis qu'une dénomination 'commune' existe, mais pour des raisons de performances ça n'est pas elle qui est utilisée le plus souvent
(pour ordre d'idée il y a environ 25000 enfants, 2000 mères et 100 pères)

Je suis tout à fait d'accord sur le "c'est plus joli/c'est plus sain/c'est mieux" mais en pratique bah c'est moins rapide ;)

Citation:

---

Envoyé par iberserk

Complétement faux :(

Char 6 stocke 6 caractères... chacun sur 1 octet.... vous ne pouvez pas stocker un octet 'binaire' sur un CHAR[1]

Ai-je été clair?:cry:

---

Non pas complétement...
il est vrai qu'un char(6) propose théoriquement autant de possibilités.

Et il est même en effet possible de convertir un nombre de 11 chiffres en CHAR(6)

par exemple :

Code:

---

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

CREATE FUNCTION BIGINT2CHAR6( @Nombre AS BIGINT ) RETURNS CHAR(6) BEGIN DECLARE @tmp VARCHAR(12) = ''   ;WITH Nb(n, char6, tmp,reste) AS ( SELECT 5, CAST(CHAR(@Nombre / POWER(CAST(255 AS BIGINT), 6)) AS VARCHAR(6)),@Nombre / POWER(CAST(255 AS BIGINT), 6), @Nombre - (@Nombre / POWER(CAST(255 AS BIGINT), 6)) * POWER(CAST(255 AS BIGINT), 6) UNION ALL SELECT n - 1, CAST(CHAR(reste / POWER(CAST(255 AS BIGINT), n)) AS VARCHAR(6)),reste / POWER(CAST(255 AS BIGINT), n), reste - (reste / POWER(CAST(255 AS BIGINT), n)) * POWER(CAST(255 AS BIGINT), n) FROM Nb WHERE n + 1 > 0 ) SELECT @tmp += char6 FROM Nb WHERE tmp <> 0   RETURN CAST(@tmp AS CHAR(6)) END   GO   CREATE FUNCTION CHAR62BIGINT( @char6 CHAR(6) ) RETURNS BIGINT AS BEGIN DECLARE @BigInt BIGINT   ;WITH Nb(n) AS ( SELECT LEN(@char6) UNION ALL SELECT n - 1 FROM Nb WHERE n > 0 ) SELECT @BigInt = SUM(ASCII(SUBSTRING(@char6, n, 1)) * POWER(CAST(255 AS BIGINT), LEN(@char6) - n)) FROM Nb   RETURN @BigInt END GO       ;WITH Test(nombre) AS ( SELECT 4568461321 union all select 98456542313 union all select 1345886594 union all select 12345678998 ) SELECT nombre AS original, dbo.BIGINT2CHAR6(Nombre) as CHAR6, dbo.CHAR62BIGINT(dbo.BIGINT2CHAR6(Nombre)) as DoubleConversion FROM test

---

:aie:

PS : si je trouve plus tordu, ça vous intéresse ? (j'ai ma petite idée pour convertir en datetime2(2), mais j'ai peur que ça coince avec DATEADD qui n'accepte pas les BIGINT comme argument...:D )


plus sérieusement et pour conclure, je pense en effet que le BIGINT est une sage décision dans ce cas !

Citation:

---

Envoyé par jo_dalton

Celle-ci existe en effet depuis qu'une dénomination 'commune' existe, mais pour des raisons de performances ça n'est pas elle qui est utilisée le plus souvent
(pour ordre d'idée il y a environ 25000 enfants, 2000 mères et 100 pères)

Je suis tout à fait d'accord sur le "c'est plus joli/c'est plus sain/c'est mieux" mais en pratique bah c'est moins rapide

---

vous avez un peu plus de 20000 lignes, autant dire de la gnognotte pour SQL Server.
Donc soit vos tables ont trop de colonnes, soit elles sont mal indexées, soit les deux ... ;)

Pour votre information, l'application sur laquelle je travaille comporte une table des personnes, dérivée par une table des patients, des employés et des docteurs.
La table des personnes contient plus de 100,000 lignes ... et personne ne s'en plaint ... pour une application de gestion d'hôpitaux, c'est plutôt normal, non ? :)

@++ ;)

Citation:

---

Envoyé par elsuket

vous avez un peu plus de 20000 lignes, autant dire de la gnognotte pour SQL Server.
Donc soit vos tables ont trop de colonnes, soit elles sont mal indexées, soit les deux ... ;)

---

Voui, pour SQL Server... Sauf que j'ai précisé 2-3 fois que c'était pour SQL Serveur COMPACT EDITION :mouarf:
Sur un pocket PC avec un CPU à max 400MHz, et des perfs qui n'ont rien à voir avec un serveur SQL malheureusement... :mouarf: :aie:

Sinon pour la conversion, elle était plutôt supposée se passer coté C#, plus simple! 8-) :aie:
Pour faire trèèèès simple, qqchse du genre:

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13

long num=...; public byte[] ToByte6(long num) { byte[] bytes=new byte[6]; bytes[0]=Convert.ToByte(num %2^8); bytes[1]=Convert.ToByte(num/2^8 %2^8); bytes[2]=Convert.ToByte(num/2^16%2^8); bytes[3]=Convert.ToByte(num/2^24%2^8); bytes[4]=Convert.ToByte(num/2^32%2^8); bytes[5]=Convert.ToByte(num/2^40%2^8); return bytes; }

---

à optimiser :mouarf:

Tiens, une interrogation, j'ai pas trop compris le sens de la phrase philosophique "l'atomicité du sens de la valeur est alors perdue"...

Citation:

---

Utiliser plusieurs colonnes de type BIT pour représenter un état

Certes cela consomme moins d'espace, mais l'atomicité du sens de la valeur est alors perdue ...
Il sera donc avantageux d'utiliser une colonne de type TINYINT qui consomme seulement un octet, en laissant la porte ouverte à de nouveaux états ...

---

QQ'un pour m'éclairer?

A vrai dire j'hésitais à passer 3 bits en tinyint, mais je ne suis pas certain de l'impact en terme de perf... Sachant qu'après ça fait un traitement supplémentaire! (Et un peu de complexité...)


Et au passage... Une ptite question qui n'a rien à voir...
Sur un proc 64bits, les comparaisons int/bigint ont le même coût en terme de perf? :zoubi: