m_theologos wrote:

>> 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.
>>
>
> Yes, but we must deal now with a SQL server. (I don't like very much
> SQL language either). Do you mean to extend the language in order to
> allow it to deal with both relational and non-relational data on
> server? And/or make API calls in order to mix the relational data
> with context free search results? The main problem is to 'join' these
> results. That's why I stated that the 'data' must get out from the
> server in a computationally-complete language to process it.
>

All data flows over an API or as literal values. The API exists to
support language semantics. Sometimes it's possible to extend the
semantics without extending the API, sometimes not. New data types, for
example, generally require an API extension. If any operation (like
search) can't be handled in the existing API, the API must be extended.

The idea that SQL is, or could be, computationally-complete is
intellectual horseshit.

> No, I didn't meant that the search is "stupid crap". I wanted to
> clearly state that perhpaps is better to do incrementally the
> features, thing which doesn't imply that we need to do half-backed
> ones. On contrary, I think that the search, and especially the
> quality of searching, is one of the most important problems today.
>

Doing a subset without considering the full feature is *always* a mistake.

> I think that this is the main difference between us. Also I think
> that it comes from the fact that I work 'datatabase apps' (with a
> presentation layer on Desktop and/or web - doesn't matter) in which a
> page with a general 'Search' edit field is rarely used, and sometimes
> dangerous.

Bad search isn't used. Search that isn't well integrated into an
application isn't used.

The web has taught us that drop down menus are bad and visible links are
good. People don't like using desk top applications because they're
obscure, hard to use, and hard to learn. Application developers build
them because it's the only thing they know how to use.

The things that distinguishes web applications from desk top
applications is that people don't have to use web applications, they
choose to do so. If a web application is obscure, hard to use, or hard
to learn, the users go somewhere else. Desk top application builds
generally have a captive audience where the users either uses the
application or quits his or her job.

> For example, issuing a Search for the word 'secret',
> looking for a product the stream will return (where? in a table? in a
> array?) something like:
>
> Products.Name: "Lord's secret" (A book, for example)
> Acc.Description: "My best kept secret account"
>

Intelligent search (why have any other kind?) is fast and presents the
hits in an ordered concise, descriptive manner. Note that it takes less
time to Google something that to drill down through most application menus.

> So, multi-table FTS searching will be rarely used and thus, perhaps,
> such a global composite index will make things slower?
>

Rarely only is badly done. And you're postulating that a global
composite index is slow. Have you noticed that Google with billions and
billions of indexed documents does searches in milliseconds? Stop and
think about that. Then drop the non-sense about performance.