Oracle Text - Indexer un champ BLOB (contenant des données PDF)

Question

Est-ce que l'un d'entre vous a déjà utilisé Oracle Text pour rechercher du contenu dans des fichiers PDF?

J'ai une table, avec un champ appelé FILEDATA (blob).

Je voudrais faire la requête suivante:

SELECT id FROM ttc.contract_attachment WHERE CONTAINS(filedata, 'EXAMPLE') > 0; 

Cependant, je ne suis pas trop sûr du type d'index d'y ajouter.

J'ai trouvé le code suivant:

begin 
    ctx_ddl.create_preference('doc_lexer', 'BASIC_LEXER'); 
    ctx_ddl.set_attribute('doc_lexer', 'printjoins', '_-'); 
end; 
/

create index idxContentMgmtBinary on CMDEMO.CONTENT_INVENTORY(TEXT) indextype is ctxsys.context 
    parameters ('lexer doc_lexer sync (on commit)'); 

Ref: http://www.devx.com/dbzone/Article/21563/1954

Je ne sais pas ce que BASIC_LEXER est. Je suis un peu perdu. Je m'efforcerai de continuer à chercher une réponse. Toute aide est la bienvenue.

Merci.

Answer 1

J'ai utilisé Oracle Text pour indexer non seulement les PDF, mais aussi d'autres données comme les structures XML. Oracle a le concept des lexers qui prennent le contenu et analysent, tokenizes et indexent les jetons. Le lexeur de base gère les mots anglais, il existe d'autres lexers pour le chinois, le japonais, le coréen, etc. L'attribut printjoin vous permet d'indexer les caractères normalement exclus tels que les traits, les guillemets, etc ...

L'index que vous avez défini ci-dessus marchera. Gardez à l'esprit que l'indexation de texte Oracle est un processus asynchrone, ce qui signifie que la validation a lieu et que le document est indexé dans le futur. Cependant, vous devrez synchroniser l'index dans le cadre d'un travail planifié ou similaire. Avec l'option "sync (on commit)" sur votre index, il va indexer le document dans le cadre de la transaction. Ceci est remarquable seulement si vous indexez des documents PDF importants. Je recommande d'utiliser la relaxation progressive pour toute recherche que vous souhaitez effectuer, car cela peut être une recherche restrictive et étendre à une recherche plus générique, fournissant ainsi à l'utilisateur des résultats qui sont de moins en moins pertinents. Par exemple:

<query> 
    <textquery lang="ENGLISH" grammar="CONTEXT"> cat dog 
    <progression> 
     <seq><rewrite>transform((TOKENS, "{", "}", " "))</rewrite></seq> 
     <seq><rewrite>transform((TOKENS, "{", "}", "AND"))</rewrite></seq> 
     <seq><rewrite>transform((TOKENS, "{", "}", "ACCUM"))</rewrite></seq> 
    </progression> 
    </textquery> 
    <score datatype="INTEGER" algorithm="COUNT"/> 
</query> 

La requête ci-dessus tokenizes les mots-clés de recherche « chien chat » tente de les trouver comme une phrase, puis tout document contient chat et de chien (pas nécessairement à côté de l'autre), puis tout document contenant chat ou chien, les documents contenant les deux mots sont notés plus haut que si un document en a un seul. De plus, la structure déduit automatiquement les résultats au fur et à mesure qu'ils les retournent.

Tout cela étant dit, vous pouvez simplement définir votre index comme:

create index idxContentMgmtBinary on CMDEMO.CONTENT_INVENTORY(TEXT) 
    indextype is ctxsys.context 
    parameters ('sync (on commit)'); 

et il serait probablement très bien pour vos besoins. Vous auriez seulement besoin de changer le comportement du lexer si vous en avez besoin. J'espère que ça aide.