Forum: Ruby on Rails Search engine that works with MS SQL Server

Announcement (2017-05-07): www.ruby-forum.com is now read-only since I unfortunately do not have the time to support and maintain the forum any more. Please see rubyonrails.org/community and ruby-lang.org/en/community for other Rails- und Ruby-related community platforms.
Bc78ecf1898c83d627f9779e0e47af15?d=identicon&s=25 Carsten Gehling (carsten)
on 2009-02-25 08:34
Can anyone recommend a search engine for Rails that works with MS SQL
Server?

I have good experience in using Sphinx and the Rails plugin UltraSphinx.
Unfortunately, it supports only MySQL and PostgreSQL. The newest beta
version does add support for MSSQLServer, but only if Sphinx is
installed on a Windows machine - and I have to run it on Debian Linux.

So if anyone knows of a similar search engine, that supports the above,
I would be very grateful. Especially if it already has a plugin for
Rails. :-)

- Carsten
A91bd6cef23eb3516245a092e196c4da?d=identicon&s=25 Maurício Linhares (mauricio)
on 2009-02-25 16:23
(Received via mailing list)
Why don't you use a full text search engine that doesn't require a
database -> http://lucene.apache.org/solr/

Can't understand why people still try to use Sphinx, when it doesn't
get any near Solr's features and doesn't update the indexes on the
fly.

-
Maurício Linhares
http://alinhavado.wordpress.com/ (pt-br) | http://blog.codevader.com/
(en)



On Wed, Feb 25, 2009 at 4:34 AM, Carsten Gehling
81b61875e41eaa58887543635d556fca?d=identicon&s=25 Frederick Cheung (Guest)
on 2009-02-25 16:56
(Received via mailing list)
On 25 Feb 2009, at 15:22, Maurício Linhares wrote:

>
> Why don't you use a full text search engine that doesn't require a
> database -> http://lucene.apache.org/solr/
>
> Can't understand why people still try to use Sphinx, when it doesn't
> get any near Solr's features and doesn't update the indexes on the
> fly.

Last time I looked (admittedly a while back) sphinx was noticeably
faster at indexing (eg see
http://blog.evanweaver.com/articles/2008/03/17/rai...
  and
http://www.mysqlperformanceblog.com/files/presenta...
  ).

As far as the original question goes Sphinx doesn't have to be able to
talk to your database if you can provide a command line tool that will
produce an appropriately formatted xml stream for sphinx.

Fred
A91bd6cef23eb3516245a092e196c4da?d=identicon&s=25 Maurício Linhares (mauricio)
on 2009-02-25 17:09
(Received via mailing list)
And it still is faster at indexing, as it isn't capable of on-the-fly
updates (if something changes, you´ll have to rebuild your index).

I see Sphinx as an option if your full text search functionality isn't
that complicated (Sphinx can't do partial matches or fuzzy search) or
your indexed models don't change much.

Solr is a full blown full text search tool with most of the features
you'll see in "enterprise" tools like fuzzy searching (that enables
things like Google's "did you mean?" feature), stop words removal,
faceting and a simple way to write your own customized filters (and
loads of documentations if you need to tweak it).

I tried Ferret and it had loads of problems, specially with concurrent
access, tried Sphinx but the lack of on-the-fly updates, partial
maches (there's a hack to get this working, but it's a hack) and fuzzy
search lead me to try Solr and now I have no reason to look back :)

-
Maurício Linhares
http://alinhavado.wordpress.com/ (pt-br) | http://blog.codevader.com/
(en)



On Wed, Feb 25, 2009 at 12:55 PM, Frederick Cheung
Bc78ecf1898c83d627f9779e0e47af15?d=identicon&s=25 Carsten Gehling (carsten)
on 2009-02-25 21:04
Maurício Linhares wrote:

> Solr is a full blown full text search tool with most of the features
> you'll see in "enterprise" tools like fuzzy searching (that enables
...

I will give Solr a go, thanks. One of the things I like about
ThinkingSphinx though is the ability to combine Sphinx's free-text
searching with other search criterias on other attributes in the model.
But I can probably do that myself in another way.

- Carsten
This topic is locked and can not be replied to.