Hello,
je fait mes premiers pas en BD. J'utilise SQL Server pour commencer, mais devrai supporter d'autres BD (Oracle, ...), donc je veux rester le + standard possible.
Mon problème : je dois stocker des enregistrements simples :
- des données binaires brutes (quelques dizaines de Ko, des nombres flottants en fait)
- une info de petite taille sur ces données
Pour l'exemple, cela reviendrait à stocker un petit fichier (DATA) accompagné de son nom (NAME). Ok.
Cas d'utilisation typique:
- faire un SELECT NAME très souvent (lister tous les fichiers dispos)
- faire un SELECT DATA WHERE xxx à petite dose (lire un fichier choisi)
 
2 questions:
1/ au niveau du stockage, est-ce que les (principaux) SGBD sont assez malins pour séparer le stockage de ces 2 champs, et ainsi pouvoir lister très rapidement tous les NAME ou est-ce qu'ils stockent ça de manière contiguë, a savoir NAME puis DATA, NAME puis DATA, ce qui rend la récupération de tous les NAME très longue...
 
2/ au niveau stockage des données binaires. Quel type utiliser ? J'ai croisé BLOB, CLOB, BINARY, IMAGE, ... y'a quelque chose de standard ? Comment entrer des données binaires via une requête ? J'utilise une source ODBC, et je lui envoie des requêtes sous forme de texte. Comment envoyer des données bianires de cette manière ?
 
Merci.

Salut.
 
1/ Te pose pas de question à propos du stockage. T'as deux valeurs distinctes, donc ce seront deux champs dans une table. Point. Ensuite, c'est au SGBD de se démerder pour te rappeler les infos que tu veux, c'est pas à toi de te demander comment il fait.
 
2/ Tu parles de données binaires, puis de nombre flotant. Alors c'est quoi ? Des données binaires, ou un nombre flotant ? Parceque si c'est un flotant, il y a un type "float" qui fera parfaitement l'affaire. Quant au name, c'est simple, varchar() et roule ma poule.
 
3/ Tant que tu ne gère pas la création de la table, alors tu n'as pas à te poser la question du type interne. ODBC est justement là pour faire en sorte qu'un FLOAT, un "REAL" ou un "DECIMAL" puissent être mis dans un type "double" depuis ton programme. C'est justement le rôle d'ODBC, de fournir une couche d'abstraction faisant le lien entre les types systèmes de ton langage et les types de la base.

En fait ce sont des flottants... binaires, sous forme binaire. J'en ai pas un , mais des centaines/milliers, sous forme brute, binaire (!= texte).
Ca me gênerai beaucoup de me taper des milliers de conversions binaire <-> texte pour mes flottants...
Faut plutot voir ça comme un tableau de flottants, au sens tableau C/C++

Ben alors tu utilises un type "image" pour SQL Server ou "blob" pour la plupart des autres SGBD.
Le fonctionnement via ODBC est le même.
 
Selon les langages, il va attendre une chaîne de caractères (codés sur 8 bits, donc pas de problème, ça reste binaire) ou un array de bytes, ou de char (synonymes)
 
Normalement, tu ne devrais pas avoir de problème.
Par contre, stocke bien le NAME dans un varchar à part.
 
Sinon, point de vue physique, un BLOG (ou IMAGE) c'est jamais stocké directement dans la table. Dans la table, tu trouve ton varchar, et un pointeur (généralement sur 16 bits) qui permet de retrouver les données IMAGE dans un fichier spécial. Mais pour toi, c'est transparent. Donc ne te pose pas de question, la recherche sera rapide, puisque les NAME ne seront physiquement séparés que de quelques octets (logiquement, 2)

pour le char, ben non, car la fin d'une chaine de car en C est déterminée par le carcatère 0, donc si j'ai un zéro à écrire, DMC...
Mais je crois avoir trouvé la solution. En fait j'utilise pas ODBC, mais une surcouche à ODBC! C'est Qt, une lib C++, qui en interne utilise ODBC, dans mon cas. J'ai trouvé un exemple (/examples/sql/blob) qui montre comment remplir un "LONGBLOB" avec un QByteArray, un type Qt. Me reste plus qu'à créer un QByteArray à partir de mes données, et à tester ça sous SqlServer, dans un champ IMAGE tu me dis. J'étudie les autres possibilités: http://msdn.microsoft.com/library/ [...] /BLOB.asp)
Donc ça se profile bien.
 

Bon ben c'est parfait alors.
 
Je te remercie.

si pour un type "image", et non "text", un drivers ODBC attend une string, alors qu'en sortie il y a du binaire, alors je pense qu'il sera capable tout seul comme un grand de virer le 0 de la fin.
 
deplus, pour peut que tu code correctement en c++, genre pas parcourir les caractères d'une chaîne à l'aide d'un offset et de pointeurs, alors la présence ou non d'un 0 dedans ne dois en aucun cas changer quoique ce soit au fonctionnement de ton prog, puisque ce 0 n'est pas lisible en utilisant les fonctions "normales".

C'est le "zéro de fin" le problème : et si c'est pas un zéro de fin, mais un zéro "de milieu" ?
Mais apparement il accepte un tableau d'octet, et non pas une string donc tout est bon.

nan, mais ce que je veux dire, c'est que si le drivers écrit dans un type qui attend du binaire, et attends une string pour écrire dedans (c'est le cas en VB par exemple), alors les fioritures liées au type string ne sont pas enregistrées dans la base, le pilote ODBC se débrouille pour n'extraire que les informations que tu désires.
 
tout comme pour ton tableau de bytes. en mémoire, je ne sais pas exactement comment c'est géré en C++, mais je doute que ce soit simplement une série d'octets contigü en mémoire, pourtant, dans la base, il n'écrit que ça.
 
quand tu fais un gateau, et que tu dois mettre 4 cuillères de sucre, ben tu ne met que le sucre, tu laisses pas 4 cuillières en acier dans la pâte ben là c'est pareil

Je crois avoir compris ta remarque. En C++ y'a un type string standard, qui possède des fioritures comme tu dis. Mais je faisais référence aux chaines de carcatère C, qui ne sont que de simples suites d'octets contigü en mémoire, dont la fin est déterminé par la présence de l'octet 0 => chaine de caractères terminée par nul => nul string. Du coup ça interdit la présence de ce caractère dans une string C.
Mais bon, vu que le problème ne se présente pas, tout va bien