I know this seems like a smart-aleck remark, but just don't go there <G>.
It goes against all your DB instincts, but you need to think about *de*normalizing our data. Maybe a useful mental trick is to think about what it would take to make a single table in a DB where all the information you needed was in a single row of that table, then index *that* schema in Lucene/SOLR. The point here is that SOLR/Lucene is built to search lots and lots of text very quickly. We call these documents (*somewhat* similar to a database row). But SOLR/Lucene doesn't do a very good job of dealing with relations between rows. When you find yourself trying this latter, back up, take a deep breath, and re-think what you're doing. This is not a knock on SOLR/Lucene, any more than saying that full text searching in a database isn't very well supported. It's a statement on the appropriateness of the tool for the application. So if you're looking for a way to map database tables into SOLR, I think you're looking at the problem from the wrong perspective. Instead, clearly define what you want it to *do*, then how SOLR/Lucene can help. It may be that you stick with a DB. It may be that you create a hybrid solution that searches text with SOLR, say returns a list of DB ids, and then does some DB work with the result. It may be that you can put everything in SOLR and be happy. It entirely depends on your problem space. Note that there are some db-like capabilities built into SOLR (I'm thinking faceting here), but those are really a distraction from the above. Decide what you want it to do. Outline some use cases, and *then* decide on the tools/approaches. Hand-waving and not very concrete I know, but expressing my absolute conviction that the problem you're trying to solve must be defined before diving into the mechanics... Best Erick On Sun, Dec 13, 2009 at 1:01 PM, Faire Mii <faire....@gmail.com> wrote: > Hi, > > I am a beginner and i wonder what a document, entity and a field relates to > in a database? > > And i wonder if there are some good tutorials that learn you how to design > your schema. Because all other articles i have > > read aren't very helpful for beginners. > > Regards > > Fayer >
