Discussion :

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

@++

[jo_dalton]

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

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

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

[elsuket]

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 ?

@++

[jo_dalton]

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
Sur un pocket PC avec un CPU à max 400MHz, et des perfs qui n'ont rien à voir avec un serveur SQL malheureusement...

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

Code :

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

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

[jo_dalton]

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

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?