views:

134

answers:

3

I've built an ASP.NET MVC application with MVC 2.0 and Fluent NHibernate (hided behind repositories for some reasons). The application represents a quite complex domain with some different objects like users, messages, comments, files and appointments.

Now I want to implement a fulltext search which is enabling the user to find easily all types of content by simply entering a search phrase. When handling all that types of different objects in the application seperately, I now have to put them "together" for the search. That means the user makes no distinction between the different types, he just enters "xyz" and wants to get results in a list, comments mixed up with messages etc.

Option 1 is to create a search service which fetches the search result from the different repositories and prepares the combined output (sorting, paging etc.). But that's really, really expensive when the data behind grows (and it will grow).

So I am looking for an alternative solution. Currently I am working with SQL Server 2008. What I have found is lucene.net (http://lucene.apache.org/lucene.net/), but I didn't invest much time yet.

Any suggestions?

+3  A: 

For .Net you can look into RavenDB which uses lucene as it's index storage, and will provide you with the search capabilities of Lucene as a bonus. It might be easier to use. Certainly more flexible and better API's imo. But you should look into the storage overhead.

Depending on your need you can turn on Full Text Search in SQL Server which gives you additional query capabilities from SQL. This way you don't need to manage another index outside your database data. If your data resides in several repositories, then using an external index like Lucene might be a better approach.

As for other full text search engines you have Microsoft Search Server Express, but you might have to create your own content connector to get the data in (again depending on your repositories).

Mikael Svenson
@jfar: Edited my answer to reflect this. I still think using RavenDB as a replacement for Lucene directly is an option due to the API's it provide.
Mikael Svenson
@Mikael Svenson - updated my vote and removed comment to reflect your edit ;)
jfar
+2  A: 

I'd definitely go with SQL fulltext capabilities. I do understand that some of the content might be available in files, other structures but even then, the majority of the data should be in the backend and SQL does a fine job with fulltext indexes architecture-wise.

I'd suggest you start with SQL fulltext and create a small component that query the other resources (if required). I'm assuming that 80% of the searchable content would be coming from SQL Server.

Here are a couple of resources to started with SQL Server fulltext:

  1. http://msdn.microsoft.com/en-us/library/ms142571.aspx
  2. http://www.dotnetfunda.com/articles/article1019-implementing-fulltext-search-on-view-.aspx?sms_ss=dotnetshoutout
Sidharth Panwar
It's even 100% of the data coming from SQL Server. So you're right, I just take the good old way, maybe even with a stored procedure or plain ADO.NET - thankfully I am still using repositories.
asp_net
A: 

Simply saying "use fulltext" isn't enough. His solution is not necessarily about having more advanced text searching within each entity type. He needs to be able to query the index for any type of entity based upon the query string. I could see using NHibernate.Search as the method to populate a Lucene index, but don't know if the capabilities of it support searching the index irrespective of the index document type (the NHibernate class being persisted). So you may have to query the Lucene index more directly and interpret the results for display or direct retrieval of the underlying object in the SQL server DB via NHibernate itself.

Rich