sql text retrieval product information

From: Kent Palm <kpalm_at_doc.qualcomm.com>
Date: Mon, 7 Dec 1992 21:17:42 GMT
Message-ID: <kpalm.723763062_at_doc>


Date: Mon, 7 Dec 92 12:26:06 PST
From: "David Strehlow <dstrehlo_at_us.oracle.com>" <dstrehlo_at_us.oracle.com>

>Is it a serious text retrieval product?
What users have told us they want is a better way of developing applications that seamlessly work across a broad range of data types. And they want to do this without losing the functionality of their existing proprietary systems. The four basic areas the product supplements the database are adding a "CONTAINS" comparison operator to SQL to hold the full-text portion of a query, application-defined datatypes constructed on top of ORACLE datatypes for handling the large files typical of unstructured information, bitmapped array text indexing to provide low overhead and good performance, and support for managing formatted documents as well as ASCII. The resulting product outperformed several major text retrieval products during internal benchmarking done by a hardware vendor.

>Are its text retrieval capabilities well integrated with the rest of the
>Oracle toolset?
SQL*TextRetrieval ships with two APIs: SQL*Forms 3.0 user exits, and C. This enables applications to be developed in Forms or Pro*C. Currently the C API includes the functions for executing queries and displaying results but does not include database setup and administration; these are done from a SQL*Forms-based user interface that is part of the product. The C API will be completed for a future release.

>Are text retrieval queries specified with SQL, or with some sort of
>proprietary text retrieval extensions to SQL?
Text (or more accurately content-based) retrieval is not part of the current SQL standard so our extensions are proprietary. However we, and others, are working through ISO and various national standards bodies to extend the SQL standard to handle a broader range of data types than it does now. In the meantime we are offering our implementation to those who need a solution available today.

>Is there a large overhead when inserting text records into the database?
There is CPU and IO requireed, obviously, but I don't have numbers that tell how much or how little. I have copied the development group in case they have these numbers.

>How much space do the text indexes use, 50%,100% of the data?
25% to 40% of the text being indexed.

>Is it fast?

Benchmarking done by a hardware vendor showed query performance on queries without proximity search were as fast or faster than major competing retrieval products; proximity search is the one areas that is still slower. The next point release of SQL*TextRetrieval speeds up proximity search.

>Thank you for any answers to any of these questions.
I hope I was able to help.

>----------------------------------------------------------------------------
> ___ : Philip Anderson, Hypermedia Group,
> /___\ : Collaborative Information Techonology Research Institute
> // \\ : 723 Swanston Street Carlton Victoria 3053 Australia
> _\\___//_ :
> /_____//__\ : Phone: +61-3-282-2496
>// \\/ \\ : Fax: +61-3-282-2444
>\\___/\\___// : E-mail: phil_at_kbs.citri.edu.au
> \___/ \___/ :
>----------------------------------------------------------------------------

Thanks,

David Strehlow                                             415.506.3115 - VOICE
US Product Marketing Manager, Text Products                415.506.7103 - FAX
Received on Mon Dec 07 1992 - 22:17:42 CET

Original text of this message