Subject | Re: [IBO] Re: FTS |
---|---|
Author | Helen Borrie |
Post date | 2004-08-13T23:37:33Z |
At 09:08 PM 13/08/2004 +0200, you wrote:
search index name that you provide, involving prefixes and suffixes. The
tables have names like "FTS$-----". So the "index name" that you decide to
use is really a root string for each family of indexes. It's a while since
I played with this but I decided at the time to define a short "alias
string" for each column that I wanted to be searchable, e.g. EMPFNAME for
Employee.Full_Name.
will comment on why it's now mandatory.
anything you like to identify the searchable column.
have a metastructure to work with, such as what the FTS components
provide. It would make it easier if it were possible to approach it with
"These are my requirements, can FTS do the things I need? If so, how?" or
"How do fuzzy-text search engines work? Would this one work for my
requirements?". The help text doesn't provide that kind of answer; it's a
walk-through of an example of use, rather than any kind of How-to.
Helen
>Helen Borrie wrote:Yes.
>
> >> ...
> >>The first problem was in "Defining search indexes".
> >>1. Whatever I selected from the "Table.Key Column", "Search column" shows
> >>only fields from the _first_ table (alphabetically).
> >
> >
> > Begin by entering a name for the index in the editbox at the left. Then
> > choose table.primary_key. You should see one item in the dropdown for
> each
> > table in the database (just compiled it here with v.4.3b).
>
>But (after you chose the table.primary_key) could you see fields for the
>table you chose?
>Or, just the same fields whichever "table.primary_key"That's because FTS builds several indexed tables associated with each
>you selected.
>Also, the length of the "name for the index" was severly limited (about 10
>chars?)
search index name that you provide, involving prefixes and suffixes. The
tables have names like "FTS$-----". So the "index name" that you decide to
use is really a root string for each family of indexes. It's a while since
I played with this but I decided at the time to define a short "alias
string" for each column that I wanted to be searchable, e.g. EMPFNAME for
Employee.Full_Name.
> >>2. The "Auxiliary" column seems to be mandatory, even though the helpSoundex, metaphone, find similar, thesaurus search, etc. Perhaps Jason
> >>states it is optional.
> >
> > It does seem so now. The FTS Help was written for a very early version of
> > the demo. I don't know why it should be, but possibly Jason has
> > implemented a mandatory case-insensitive search in this version of the
> demo.
>
>Still, I don't really see what I should use this for (it may dawn upon me
>later, though).
will comment on why it's now mandatory.
>Maybe I should just specify the shortest field, or the PK.The index name isn't the name of a column or index in your DB. It can be
anything you like to identify the searchable column.
>I've been using a form of homebrew FTS for some years, and wondered whetherMaybe. :-) Fuzzy text searching is a big thing to tackle, even when you
>I should convert to the IBO version. Maybe I should wait a bit.
have a metastructure to work with, such as what the FTS components
provide. It would make it easier if it were possible to approach it with
"These are my requirements, can FTS do the things I need? If so, how?" or
"How do fuzzy-text search engines work? Would this one work for my
requirements?". The help text doesn't provide that kind of answer; it's a
walk-through of an example of use, rather than any kind of How-to.
Helen