Stocker un Array of Byte en BDD

**phoenixgreg** · 14/03/2016, 15h35

Bonjour,

j'ai encore une question, selon vous quel est le meilleur moyen de stocker un tableau de byte en BDD (SQL Server) ? :

Code :

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

1
2
3
4
5
6
Array[0] := Format('%2.2d',[Integer(aby_mid[0])]);
Array[1] := Format('%2.2d',[Integer(aby_mid[1])]);
Array[2] := Format('%2.2d',[Integer(aby_mid[2])]);
Array[3] := Format('%2.2d',[Integer(aby_mid[3])]);
Array[4] := Format('%2.2d',[Integer(aby_mid[4])]);
Array[5] := Format('%2.2d',[Integer(aby_mid[5])]);

Ce qui me donne visuellement -> Array[03,00,01,00,00,46]

Il faudrait donc que je stocke cette valeur -> 030001000046.

Alors est-ce que ça le fait de la passer en string pour la mettre en BDD, puis la relire en BDD pour remplir à nouveau un tableau de byte ?

Je vous remercie pour vos avis !

**tourlourou** · 14/03/2016, 16h04

Les BLOBs sont faits pour ça, stocker des suites d'octets dont le format n'a pas à être connu de la BDD.

**phoenixgreg** · 14/03/2016, 16h24

Yep même si je ne pense pas avoir trop le choix, je trouve ça un peu lourd un champ blob pour un numéro de 5 bytes :s
Merci à toi

**SergioMaster** · 14/03/2016, 16h47

Bonjour,

sauf que

Il faudrait donc que je stocke cette valeur -> 030001000046.

est un string de 12 char ou encore un blob text (inutile) de même taille
alors que tu pourrais stocker dans un blob binaire cela donnera (hexadécimal) x03x00x01x00x00x2E soit 6 octets

**ShaiLeTroll** · 14/03/2016, 17h04

SQLSERVER, tu peux utiliser un VARBINARY(6), cela n'est pas plus lourd qu'un VARCHAR(6) et presque deux fois moins lourd qu'un VARCHAR(12)
et si ton champ fait TOUJOURS 6 Bytes, dans ce cas utilise un BINARY(6) qui est un poil plus léger que le VARBINARY(6)

Tu pourras même manipuler ton BINARY(6) via une chaine 0h03000100002E en Hexa et non en Décimal (voir ton autre sujet %2.2x

)

Enfin, ce n'est que 6 octets, SQL Server peut gérer du 64 bits via un BIGINT
En Delphi, c'est un TLargeintField
Je l'utilise en ORACLE sur des NUMBER(15)
En SQL SERVER, utilise un NUMERIC(12), cela acceptera ton grand nombre décimal 030001000046
Sur Sybase, j'ai un souvenir de manipulation de champ de bits de 128o et mon collègue avait eu des soucis, l'opérateur qu'il utilisait ne supportait que 64bits,
il avait fallu changer de fonction pour manipuler de long binaire ce qui n'est pas ton cas, donc toi les opérateurs de base supporteront ton 48bits !

Si tu utilises un NUMERIC(12) ou un BIGINT pense à faire un PAD pour ajouter les Zéros

Extrait d'une vieille lib D7 où j'avais une problématique de Pad de TLargeintField

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
function IntToStrStuff(const AIntValue: Int64; AStuffLen: Integer): string;
begin
  Result := StrZeroStuff(IntToStr(AIntValue), AStuffLen);
end;
 
function StrZeroStuff(const AStr: string; AStuffLen: integer): string;
begin
  // Maximum 2^32 donc problablement insuffisant
  // Si caractère non numérique, ça plante
  // Result := Format(Format('%%.%dd', [AStuffLen]), [StrToIntDef(Trim(AStr), 0)]);
  Result := Trim(AStr);
  if Length(Result) < AStuffLen then
    Result := StringOfChar('0', AStuffLen - Length(Result)) + Result;
end;

Code sql :

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

1
2
INSERT INTO TOTO(ChampBlob) VALUES (0h03000100002E);
UPDATE TOTO SET ChampBlob = 0h03000100002E;

Même si il serait préférable d'utiliser un TParam.LoadFromStream

**tourlourou** · 14/03/2016, 17h12

Oui, un BLOB (binaire), c'est riche pour ça ! Personnellement, je verrais plus à avoir une structure conditionnelle qui puisse être vue comme un tableau de 6 octets ou un QWord, et hop le AsInteger sur un champ entier non signé de 8 octets ! Et tu perds 2 octets pour ta structure (à la longue, ça fera pê beaucoup...)
Déclaration du style :

Code :

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

1
2
3
4
5
6
type
  TMyVarRec = record
  case Boolean of
   True  : (AOB: array[0..5] of Byte) ;
   False : (Int: QWord);
  end;

**ShaiLeTroll** · 14/03/2016, 17h29

Envoyé par tourlourou

Et tu perds 2 octets pour ta structure (à la longue, ça fera pê beaucoup...)

Ce n'est même pas obligatoire d'avoir ces deux octets supplémentaires

Mais ton idée donne encore une autre piste que j'utilisais pour stocker en Paradox des codes-barres EAN13 sur trois champs Integer 6+6+1 au lieu d'un champ 13 char, la recherche était juste deux fois plus rapide !

tu peux utiliser deux colonnes entière, un smallint et un int
SQL SERVER gère ces types en T-SQL, à vérifier si c'est bien des types supportés en SQL

De plus avec le little endian, en jouant sur la mémoire comme ça, cela ne va pas stocker les valeur à l'envers ?

Code :

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
type
  TMyVarRec8 = record
    case Boolean of
     True  : (AOB: array[0..5] of Byte) ;
     False : (Int: Int64); // Int64 c'est le type natif 64bits, QWord est un type Windows mais c'est la même chose
  end;
 
  TMyVarRec6 = packed record // pour éviter un alignement
    case Boolean of
     True  : (AOB: array[0..5] of Byte) ;
     False : (LowPart: DWord;
              HighPart: Word;
              );
    end;
var
  vr8: TMyVarRec8;
  vr6: TMyVarRec6;
begin
  vr8.Int := 0; // vaut mieux sinon deux octets aléatoire
  vr8.AOB[0] := 03;
  vr8.AOB[1] := 00;
  vr8.AOB[2] := 01;
  vr8.AOB[3] := 00;
  vr8.AOB[4] := 00;
  vr8.AOB[5] := 46;
  ShowMessage(Format('%.16x', [vr8.Int])); // donne 00002E0000010003, oh le casse-tête en base d'avoir la valeur inversée !
 
  vr6.AOB[0] := 03;
  vr6.AOB[1] := 00;
  vr6.AOB[2] := 01;
  vr6.AOB[3] := 00;
  vr6.AOB[4] := 00;
  vr6.AOB[5] := 46;
  ShowMessage(Format('%.4x%.8x', [vr6.HighPart, vr6.LowPart])); // donne 2E0000010003, plus court mais toujours inversé !
end;

ce qui n'est qu'une variante du

Code :

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

1
2
3
4
5
6
7
8
  _LARGE_INTEGER = record
    case Integer of
    0: (
      LowPart: DWORD;
      HighPart: Longint);
    1: (
      QuadPart: LONGLONG);
  end;

Mais bon, BINARY(6) c'est prévu pour ! autant l'utiliser !
Et au pire, tu peux isoler tes binaires dans une table secondaire (cela oblige une jointure, est-ce intéressant pour un si petit blob) et éviter les SELECT *

**phoenixgreg** · 15/03/2016, 08h44

Ok déjà merci pour vos pistes bien fournies. Je pense que je vais passer par un champ NUMERIC(12) pour SQL Server, ce qui me posait soucis c'était de garder tous les zéros en effet mais ShaiLeTroll a trouvé une solution apparemment (qu'est-ce qu'un PAD ? padding ?)

Je vais pianoter et je vous dis comment ça se passe !