Salut,
 
une petite question : est-il possible de compresser le contenu d'un champ d'une table sous MSQL Server ?  
En fait mon problème est le suivant: J'ai des données relativement grosse (>8000 caractères) et comme le type varchar est limité à 8000 caractères, je suis obligé d'utilser le type text ou ntext pour la stocker. Ce qui ne m'arrange pas du tout ... Je voudrais donc pouvoir conserver le type varchar et pour cela il me faudrait compresser le contenu de ce champ pour qu'il fasse moins de 8000 caractères ...
 
Avis aux suggestions ... merci

Bah tu compresses d'abord et tu insères dans ta base ensuite...Je vois pas trop le rapport avec les SGBD/le SQL, là.

 
+1

En tout cas, t'as pas intérêt à devoir faire une recherche dedans après
 
Moyen qu'on utilise ici (le type BLOD d'Oracle est tellement bugué au niveau ODBC - et de toute façon mal supporté par le moteur d'Oracle - qu'il est interdit de l'utiliser), c'est qu'on crée plusieurs champs de type varchar, et au moment de l'insertion, on découpe le texte en tronçons de 8000 caractères

j'ai peut être mal expliqué mon problème ... mais effectivement le but est de stocker l'info en compressée et de pouvoir y avoir accès par la suite avec des requête en non compressée ... donc il faut une compression interne au SGBD sinon ca va pas aller ...

cf solution d'arjuna dans ce cas je pense...

l'idée de couper les données en morceaux de 8000 caractères est pas mal mais doit être couteuse ensuite pour accéder aux données via des requêtes ???

Probablement moins couteux (et surtout moins chiant à mettre en place) que de compresser/décompresser à la volée systématiquement...non?

d'autant plus que je ne connais pas de SGBD capable de compresser/décompresser à la volée du texte... surtout dans un champ d'une taille de 8 Ko, où de toute façon, même la compression la plus efficace n'aura qu'un impact extrêment réduit (je vois pas l'intérêt de pouvoir stocker 10% de texte en plus quand la limite est aussi faible...) Gagner 80% sur un blob de 2 Mo, ce serait déjà plus intéressant.

arjuna : oracle peut compresser un champ colonne texte en 9i, c'est meme conseillé non ?

Qu'il puisse, peut-être. Que ce soit conseillé, j'en doute plus qu'énormément. Déjà que le texte c'est merdique à souhait niveau perfs, alors si en plus il est compressé...
 
Que tu puisse compresser un LONG, à la limite, Oracle ne sait pas s'en servir...

sisi ca a d'ailleurs fait pas mal de bruit parmi les expert oracle
faudrait que je retrouve le lien
en fait le temps de compression est infime par rapport au temps d'un io supplementaire pour chercher plus de texte
genre si en compressant un champ tu t'epargne un io, tu gagnes largement par rapport au temps de compression/decompresion

Mmmmm... Quand je vois à quoi une SAN ressemble, j'ai du mal à accorder du crédit à ce genre de théories. Pour un petit serveur, peut-être.
 
Deplus, dans tous les cas, un varchar faisant 8 Ko au maximum, en une IO tu lis quelques milliers de champs de ce type. C'est pas l'économie d'une IO qui fait gagner du temps.
Par contre, pour un LONG dont le contenu peut atteindre 2 Go, là oui, la compression est intéressante, surtout qu'Oracle est incapable de faire le moindre traîtement dessus.
 
PS: si la compression permettait de gagner autant, tous les serveurs tournant sur de la NTFS (dont le FS permet la compression des fichiers) uiliseraient ce système, et ce serait même pas Oracle qui s'en chargerait. Et pourtant, c'est un truc que même M$ qui est l'auteur du FS déconseille vivement sur ce type de serveurs. Ce n'est à utiliser que sur un serveur de stockage (Serveur de fichiers, serveur de backup, etc.)

heu en un IO tu lis qlq milliers de champs de 8k ????
genre tu lis 8k*1000 = 8Mo en un IO ? faudra me donner tes disques, ca m'interesse grandement :-)
oublie pas que le san est pas encore partout
 
par defaut sous NT tu lis 2k pour un io selon tes proprietes ntfs
 
si je retrouve l'article, je t'enverra l'url
et oui je suis d'accord la compression ntfs est totalement pourrie, lente et bugguée

vla  
http://www.oracle.com/technology/o [...] ecomp.html
c'est pas forcement objectif parce que ca vient d'oracle mais ca avait ete confirme independament
je t'accorde egalement que ca ne convient pas partout mais un collègue en a tire des bonnes perfs

Bah...
 
Un SAN c'est 100 disques en RAID 50, je peux te dire qu'en un seul accès très plus proche du Go de lecture que du Mo
 
C'est d'ailleurs pour ça qu'un SAN est systématiquement équipée de plusieurs interfaces fibre optique maintenant (avant c'était des interfaces SCSI en //)