Stocker un Array of Byte en BDD

Bonjour,

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

Code:

---

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 !

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

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

Bonjour,

sauf que

Citation:

---

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

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 :mouarf:)

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:

---

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:

---

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

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:

---

1 2 3 4 5 6

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

---

Citation:

---

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

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

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:

---

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 *

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 !

Padding = remplissage : ajouter des zéros (souvent) pour respecter la longueur d'une structure et l'alignement des données (utiles) dans celle-ci.

C'était logique mais je préfère demander ^^ et un pti pouce vert pour toi ! :p