m_theologos wrote:

> ResultList
>
>> that can be iterated similar to a ResultSet, but the "value" of a
>> ResultList is a ResultSet rather than a scalar value.
>>
>
> And so, you'll take out the result from the server's engine. The
> entire processing must be done on the client side building the
> appropiate functions from scratch. I rather prefer a more SQL
> approach, using JOINS, Views aso.
>

Your conclusion on what is server and what is client is both
unwarranted and wrong.

Context free search is the the sine qua non of the web. The fact that
they can't be expressed in SQL is a deficiency of SQL, not the web.
Your insistence that search must be mapped into semantic defined in the
early 1980's is just another example of how database guys don't "get"
search. The computing world as shifted since Codd defined the
relational database.

>>> I'd say that suggested keyword search is a simplified version of
>>>
> MATCH operator that accesses a multi-field FTS index, however only for
>
> one table. Having that case implemented would be of great benefit for
> Firebird, considering amount of applications that use FTS via SQL.
> Don't you agree?
>
>
>
> I agree. And I think that is easy to implement it. Of course if you
> want a more advanced approach the things change. Then we'll do a more
> dedicated structure, IMHO. If you're interested, drop a line.
>

The implementation of the index the same whether it is single field,
single table, or multi-table. The only difference is what id's are
carried; the logic is identical.

> Also, please observe that, generally speaking, each column to be
> indexed tend to has its own vocabulary.

Why is this significant? And in any case, the aggregate size of
multiple indexes will alway be much greater than the sum of the sizes of
individual indexes. Search across multiple indexes will also be much
slower (and harder to implement) than a combined index.

I think you need to understand how word indexes are searched before
jumping to unwarranted conclusions.

> I think that (IMHO) is better to implement step-by-step things (no
> stupid crap inside the engine of course), rather than leaving
> unimplemented a feature because we cannot make it perfect from the
> beginning.
>

I'm sorry you think that search is "stupid crap". I hope most people
disagree with you.

> ...but please take in consideration that behind the web page is an
> app which deals with concrete kinds of data orgainzed in tables,
> "kinds" from _human_ point of view (I don't mean here 'data types'),
> so as you observed, 'There are good uses for a heavily restrictive
> search...' In conclusion, I think that a multi-table multi-field FTS
> index is good to have but having only this is a 'heavy' thing to deal
> with IMHO. (No SQL, lack of speed, difficult to refine aso.)
>

I haven't argued against a restricted search. Netfrastructure, in fact,
supports restriction to specific tables or fields in both the API and
SQL extensions. That isn't the issue. The issue is whether a combined
multi-table, multi-column index is better or worse than single field
index. Clearly the multi-table/field index can be used to search a
single field efficiently. Do you claim the reverse is true -- that a
multi-table, multi-field search based on an indeterminate number of
individual field indexes is efficient?


--

Jim Starkey, Senior Software Architect
MySQL AB, www.mysql.com
978 526-1376