Comment gérez-vous efficacement les données BLOB et numériques dans la communication de base de données?

Question

Les bases de données SQL semblent être la pierre angulaire de la plupart des logiciels. Cependant, il semble optimisé pour les données textuelles. En fait, lorsque vous effectuez des requêtes impliquant des données numériques, des nombres entiers spécifiquement, il semble inefficace que les nombres soient convertis en texte et retournent ensuite aux formats natifs dans les deux sens entre l'application et la base de données. Cette même inefficacité semble également s'appliquer aux données BLOB. Ma compréhension est que même avec quelque chose comme Linq to SQL, cette conversion bidirectionnelle se produit en arrière-plan.

Existe-t-il des moyens généraux de contourner cette surcharge avec SQL? Existe-t-il certains systèmes de gestion de base de données qui traitent cela plus efficacement que d'autres (par exemple, avec des extensions/API non standard)?

Clarification. Dans l'instruction select suivante, la liste des nombres après IN pourrait être plus facilement transmise sous la forme d'un tableau brut de int, mais il semble qu'il n'y ait aucun moyen d'atteindre ce niveau d'optimisation.

SELECT foo FROM bar WHERE baz IN (23, 34, 45, 9854004, ...) 

Answer 1

Les données numériques d'une base de données ne sont pas stockées en tant que texte. Je suppose que cela dépend de la base de données, mais ce n'est certainement pas le cas.

Les BLOB sont stockés exactement comme vous les avez définis - par définition, le DB n'a aucun moyen d'interpréter les informations - je suppose qu'il pourrait compresser s'il trouvait cela utile. Les BLOB ne sont pas traduits en texte.

Voilà comment le nombre de magasins Oracle:

http://download.oracle.com/docs/cd/B28359_01/server.111/b28318/datatype.htm#i16209

Format numérique interne

stocke Oracle Base de données des données numériques dans le format de longueur variable. Chaque valeur est stockée en notation scientifique, avec 1 octet utilisé pour stocker l'exposant et jusqu'à 20 octets pour stocker la mantisse. La valeur résultante est limitée à 38 chiffres de précision. Oracle Database ne stocke pas les zéros de début et de fin. Par exemple, le nombre 412 est stocké dans un format similaire à 4.12 x 102, avec 1 octet utilisé pour stocker l'exposant (2) et 2 octets utilisés pour stocker les trois chiffres significatifs de la mantisse (4,1,2). Les nombres négatifs incluent le signe dans leur longueur.

information MySQL ici:

http://dev.mysql.com/doc/refman/5.0/en/numeric-types.html

Regardez la table - un TINYINT est représenté dans 1 octet (comprise entre -128 et - 127), pas possible si elle est stockée sous forme de texte.

EDIT: Avec la clarification - je dirais utiliser l'API dans votre langue qui ressemble à quelque chose comme ça (pseudocode)

stmt = conn.Prepare("SELECT * FROM TABLE where x in (?, ?, ?)"); 
stmt.SetInt(0, x); 
stmt.SetInt(1, y); 
stmt.SetInt(2, z); 

Je ne crois pas que les protocoles sous-jacents utilisent du texte pour le transport de paramètres.

Answer 2

Ne supposez pas. Mesure.

La conversion de format n'est pas susceptible d'être un coût mesurable pour le travail de base de données, sauf si vous utilisez abusivement la base de données en tant que moteur arithmétique.

Le coût d'E/S pour les objets LOB, en particulier pour les CLOBS avec conversion de caractères, peut devenir important; Le remède ici, une fois que vous savez que la chose la plus simple qui pourrait fonctionner a un impact notable sur les performances, est de minimiser le nombre de fois que vous copiez les données LOB. Utilisez n'importe quel style de liaison de paramètre SQL vous permettant de transférer les données directement entre leur point de création ou d'utilisation et la base de données - souvent, cela lie le LOB à un canal de flux ou d'E/S. Mais ne le faites pas jusqu'à ce que vous ayez un moyen de mesurer l'impact, et ayez des mesures montrant que ceci est votre goulot d'étranglement.