Subject | Re: [Firebird-Architect] Re: Google-like scoring in databases |
---|---|
Author | Jim Starkey |
Post date | 2003-07-01T19:28:59Z |
Roman Rokytskyy wrote:
First, yes, you definitely need a free text search capability in
Firebird. Don't know how you
got this far without it.
Second, can be be a plug-in, or should it be an integral part of the
engine? Part of the
engine for the following reasons:
1. Somebody needs to keep track of which fields are searchable, i.e.
word-indexed.
2. Somebody needs to maintain the word index for all insert,
updates, and deletes of
records that contain searchable fields.
3. Somebody needs to map between table and fields names on numeric
ids (or pay
a ghastly penalty for failure to do so).
4. Somebody needs to be able to fetch records quickly by table id
and record number.
5. The DML needs an extension to search explicit table fields has
part of the boolean,
which requires integration with the optimizer
6. The native APIs and associated plumbing needs to be extended to
support search
semantics.
#6 is pretty much a show stopper for a plug-in unless somebody wants to
figure out to
to do plumbing plug-ins.
>I'm looking for an answer if we need search engine within the FirebirdLet me try some candidate answers.
>RDBMS. In Fulda I was discussing plugin architecture of Firebird to be
>able to add text search engine and make it available to server-side
>code (similar to DB2 Text Extender and Oracle interMedia).
>
>
First, yes, you definitely need a free text search capability in
Firebird. Don't know how you
got this far without it.
Second, can be be a plug-in, or should it be an integral part of the
engine? Part of the
engine for the following reasons:
1. Somebody needs to keep track of which fields are searchable, i.e.
word-indexed.
2. Somebody needs to maintain the word index for all insert,
updates, and deletes of
records that contain searchable fields.
3. Somebody needs to map between table and fields names on numeric
ids (or pay
a ghastly penalty for failure to do so).
4. Somebody needs to be able to fetch records quickly by table id
and record number.
5. The DML needs an extension to search explicit table fields has
part of the boolean,
which requires integration with the optimizer
6. The native APIs and associated plumbing needs to be extended to
support search
semantics.
#6 is pretty much a show stopper for a plug-in unless somebody wants to
figure out to
to do plumbing plug-ins.