Forum |  HardWare.fr | News | Articles | PC | S'identifier | S'inscrire | Shop Recherche
1340 connectés 

  FORUM HardWare.fr
  Programmation
  SQL/NoSQL

  Compresser un champ dans une table sous SQL server

 



 Mot :   Pseudo :  
 
Bas de page
Auteur Sujet :

Compresser un champ dans une table sous SQL server

n°844890
mbibim
Posté le 08-09-2004 à 11:23:52  profilanswer
 

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

mood
Publicité
Posté le 08-09-2004 à 11:23:52  profilanswer
 

n°844893
skeye
Posté le 08-09-2004 à 11:30:27  profilanswer
 

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à. :??:


---------------
Can't buy what I want because it's free -
n°844902
HappyHarry
Posté le 08-09-2004 à 11:37:40  profilanswer
 

skeye a écrit :

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

n°844915
Arjuna
Aircraft Ident.: F-MBSD
Posté le 08-09-2004 à 12:03:38  profilanswer
 

En tout cas, t'as pas intérêt à devoir faire une recherche dedans après :lol:
 
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 :D

n°845002
mbibim
Posté le 08-09-2004 à 13:55:13  profilanswer
 

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 ...

n°845003
skeye
Posté le 08-09-2004 à 13:55:53  profilanswer
 

mbibim a écrit :

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...[:skeye]


---------------
Can't buy what I want because it's free -
n°845005
mbibim
Posté le 08-09-2004 à 13:56:52  profilanswer
 

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

n°845007
skeye
Posté le 08-09-2004 à 13:57:40  profilanswer
 

mbibim a écrit :

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?


---------------
Can't buy what I want because it's free -
n°845204
Arjuna
Aircraft Ident.: F-MBSD
Posté le 08-09-2004 à 16:36:39  profilanswer
 

skeye a écrit :

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.

n°849104
surfacing
Posté le 13-09-2004 à 20:03:03  profilanswer
 

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

mood
Publicité
Posté le 13-09-2004 à 20:03:03  profilanswer
 

n°849109
Arjuna
Aircraft Ident.: F-MBSD
Posté le 13-09-2004 à 20:12:04  profilanswer
 

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...


Message édité par Arjuna le 13-09-2004 à 20:12:25
n°849116
surfacing
Posté le 13-09-2004 à 20:19:33  profilanswer
 

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

n°849125
Arjuna
Aircraft Ident.: F-MBSD
Posté le 13-09-2004 à 20:25:06  profilanswer
 

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

n°849140
surfacing
Posté le 13-09-2004 à 20:42:04  profilanswer
 

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

n°849146
surfacing
Posté le 13-09-2004 à 20:48:51  profilanswer
 

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

n°849150
Arjuna
Aircraft Ident.: F-MBSD
Posté le 13-09-2004 à 20:52:16  profilanswer
 

surfacing a écrit :

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


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


Aller à :
Ajouter une réponse
  FORUM HardWare.fr
  Programmation
  SQL/NoSQL

  Compresser un champ dans une table sous SQL server

 

Sujets relatifs
Question bête en SQL !!business objects supporte t'il le PL/SQL ?
recherche moteur de recherche pour sqlRecherche programmeur php/sql - Urgent
Changer code page SQL Server 7[access] utilisation d'une requete qui reflète une table.
generation de requetes sql a partir du code[PHP/SQL] Recuperer la clé d'un enregistrement
probleme client attente d'une connexion server 
Plus de sujets relatifs à : Compresser un champ dans une table sous SQL server


Copyright © 1997-2018 Hardware.fr SARL (Signaler un contenu illicite / Données personnelles) / Groupe LDLC / Shop HFR