Discussion :

[jo_dalton]

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

[iberserk]

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

Et combien de sorties? C'est important

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.

[elsuket]

Bonjour,

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

@++

[iberserk]

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

Code :

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

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.

[aieeeuuuuu]

Bonjour

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 ?

[elsuket]

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

@++

[jo_dalton]

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

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.

[aieeeuuuuu]

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 :

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

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

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 ?

[elsuket]

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

@++

[jo_dalton]

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] ?

[jo_dalton]

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

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

[aieeeuuuuu]

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

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

[jo_dalton]

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

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

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.

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

Peut être, mais pas pour ce cas là

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!

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.

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

[iberserk]

Code :

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

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]

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

[jo_dalton]

Code :

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

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]

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

[iberserk]

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?

[elsuket]

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.

@++

[aieeeuuuuu]

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?

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 SQL :

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

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


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