Utiliser un CLOB comme champ texte ?

Bonjour a tous,
Tout d'abord je tiens a preciser que c'est la premiere fois que j'utilise les LOB avec Oracle.

Je suis en train de creer une couche d'abstraction de BDD pour un CMS afin de l'utiliser avec Oracle, je m'aide donc de l'existant (fonctionnant avec MySQL et Postgre) pour creer cette couche.

Cependant je me heurte a un probleme de taille, la gestion des colonnes de type "text" (longtext etc).

Logiquement, vu la limite des varchar2 a 4000 caracteres, je me suis mis a utiliser des CLOBs. Malheureusement je les trouve assez contraignants.

Tout d'abord il est impossible de les mettre dans des clauses d'agroupement (GROUP BY, DISTINCT), cela me retourne une erreur 932 d'inconsistence de type - d'ailleurs la doc precise que ce n'est pas possible...

Ensuite, je fais face a la limite de 4000 caracteres pour l'insertion dans un CLOB. En gros je ne peux pas faire ca :

Code:

---

1 2 3

UPDATE ma_table SET mon_clob = 'tres long texte' WHERE id = 1

---

Où tres long text fait plus de 4000 caracteres.

Enfin, il n'est pas possible de faire la requete suivante :

Code:

---

1 2 3

SELECT * FROM ma_table WHERE mon_clob = 'mon texte'

---

Il faut que je convertisse mon clob en utilisant TO_CHAR et evidemment il ne faut pas que "mon texte" depasse la limite des 4000 caracteres.

Pour surpasser cette limite, je suis oblige de lier (bind) mon_clob a une variable externe (oci_bind_by_name en php) ce qui est assez deplaisant a faire.

Bref voila le genre de limitations auquelles je me trouve confronte. Sachant que je ne les rencontre pas avec les colonnes texte de MySQL et Postgre et je me demande bien comment je pourrais les surmonter afin d'avoir un code uniforme pour chacune des mes couches d'abstraction (rien que l'histoire des variables liees me donne des boutons...) ?

Généralement, ce genre de problème relève plus d'un défaut de conception plutot qu'un défaut de langage...

Il faut voir les LOB comme des objets à part entières. Il ne sont généralement pas dans le même espace que la table elle même, ils ne réagissent pas de la même manière que les autres types de colonnes et c'est bien normal.

Je m'imagine mal faire une recherche dans une table de 5 millions d'enregistrements contenant chacune un CLOB de quelques megs, en mettant comme seule condition de recherche

Code:

---

CLOB = 'texte très très très long'

---

Le résultat prendrait 360 millions d'années à sortir et le commentaire serait probablement que qu'ORACLE ne sort pas de résultats dans des délais raisonnables...

L'idéal est d'utiliser ORACLE TEXT pour la recherche. Sinon, des procédure existantes dans DBMS_LOB (instr, par exemple) peuvent vous aider à y faire des recherches, mais généralement, pas sur toute la table, il faut mettre au moins un filtre restrictif sur d'autres colonnes de la table afin de ne pas tomber en full scan.

Pour ce qui est de les mettres dans des group by, encore une fois, c'est pas normal d'avoir à mettre un LOB dans un disctinct ou un group by... Probablement un défaut de solution.

Pour faire de l'update, il faut passer par une procédure PL/SQL, avec un update et une variable afin de pouvoir mettre à jour ces types de données.

Je remarque que vous désirez faire ceci via PHP. Je ne peux pas vous aider pour cette partie, désolé.

Merci pour votre message.

Cote conception, j'avoue que je suis un peu demunis car comme je l'expliquais, il s'agit de rajouter le support Oracle a un CMS existant, donc je ne pense pas que je vais refaire tout le CMS justeque cela fonctionne avec Oracle.

J'ai bien conscience que les LOB sont des objets et sont geres d'une maniere differente. Cependant, MySQL et Posgre fonctionnent pas mal avec des colonnes de type texte sans avoir ce genre de limitations, d'ou mon desarroi.
Je suis cependant tout a fait d'accord avec vous, je pense que je suggererai qques patches le moments venu pour quitter les GROUP BY sur les CLOBs.
En ce qui concerne le "ORACLE TEXT", je ne m'y suis pas trop interesse du fait que cela impliquerait des faire des requetes ne fonctionnant qu'avec Oracle. Le but de cette couche d'abstraction etant de faire des requetes le plus generique possible et de passer par des fonctions qui gerent la specificite de chaque RDBMS.

A ce propos, c'est bien la mon principal obstacle lors de l'usage des CLOBs, je suis oblige de les lier a des variables (PHP en l'occurrence) et c'est vraiment pas commode du tout, la ou MySQL et PosgreSQL se contentent d'un

Code:

---

1 2	UPDATE ma_table SET mon_clob = 'tres long texte'

---

Sans avoir de probleme avec la taille de mon texte ;)

Citation:

---

Pour faire de l'update, il faut passer par une procédure PL/SQL, avec un update et une variable afin de pouvoir mettre à jour ces types de données.

---

Suggeriez vous qqch du genre :

Code:

---

1 2	UPDATE ma_table SET mon_clob = UPDATE_mon_clob('tres long texte')

---

Dans ce cas la procedure "UPDATE_mon_clob" ferait une sorte de conversion de maniere a ne pas marquer d'erreur ? Auriez vous un exemple de ce que vous me propose ?

Merci de votre commentaire.

Je pensais plutot à quelque chose du genre

Code:

---

1 2 3 4 5

PROCEDURE UPDATE_CLOB(VAL_A _MAJ CLOB) IS BEGIN UPDATE ma_table SET mon_clob = VAL_A_MAJ WHERE PK = 'VAL_PK'; END UPDATE_CLOB;

---

La raison pour laquelle la gestion des LOB avec ORACLE est plus compliqué est probablement simple : La performance du SGBDR n'est nullement comparable à MYSQL. Le besoin qu'on veut en faire aussi!

Pour ce qui est de la couche d'abstraction, l'idées est très bonne et justifiée, cependant, ce sont dans les généralitées que ces couches sont utiles et effeicaces. Lorsqu'on arrive dans les subtilitées d'un outil ou d'un produit, les couches générales ne font plus la job, d'où probablement vous déploierez beaucoup d'effort pour cette simple chose. JE vous conceille de faire une procédure stockée dans la base de données afin de pouvoir lui passer le relais de la mise à jour de cette colonne. Vous devrez, à l'installation de votre couche d'abstraction, installer ce code dans la base de données et le tour est joué.

Simple comparaison : La raison pour laquelle il n'existe pas d'outil commun pour administrer tous les SGBD est qu'ils sont tous différents. Faire UN outil pour tous les gérer couterait aussi cher voire même plus que faire le nombre d'outils correspondant au nombre de SGBD!

Excusez mon intrusion dans votre conversation super interessante, mais j'aimerai savoir ce qu'est un CMS !

Content Management Server.

Passez par le PL/SQL

Code:

---

1 2 3 4 5 6 7 8

Declare LC$Clob CLOB ; Begin LC$Clob := Lpad( '*', 32000, '*' ) ; update TEST_CLOB set TEXT = LC$Clob Where ROWNUM <= 1 ; End;

---

cms = Content management system