On Fri, 11 Mar 2005 12:34:55 +0100, Ivan Prenosil
<Ivan.Prenosil@...> wrote:

> But you have to declare/create udfs and stored procedure anyway,
> so few additional triggers wont make much difference ?

Yeah, you got some point there. I'm thinking of a "check if the trigger/function
declaration/stored procedure exists, then update/create it". And yes,
I think I've settled my mind on creating additional triggers. :)

> For searching across more tables the SP will also return table
> name, right ?

Well, no.
What would be an example for "searching across more tables"?

The current system we are using works this way:
You do update/insert/delete calls with a certain key (in our case,
it's always the primary key of the hierarchical top-most table). The
text that is assigned to this key, includes every field of the
main and/or linked tables, concatenated together. So when
you have a table setup like this:

table A is the "main" table, with a detail table B,
and the search fragments are configured to include A.name and B.name,
you'll always get A's primary key when searching for a name that's included
in B.name. There's no way to get B's primary key.
Well, this works for us. Perhaps it doesn't do for others.
I'll have to think about this for a while... thanks for the valueable comment.

> > Alternatively, I can re-index the whole tables every x minutes,
>
> Aha, so you will index only small databases if you can consider
> such approach.

No, not at all. The main table is only 25.000 datasets, but it's
a rather largish address database, with many linked tables.

> By current solution, do you mean client connects to external ft system,
> or that the index is stored in Firebird db ?

We have a library that implements a very fast text fragment search.
Unfortunately, it doesn't run on *NIX systems and the license isn't
free.

--
eat(this); // delicious suicide