Dedicated faceted search engine for dealing with dynamic taxonomies - helps just with performance or also flexibilty?

Question

I\'ve been thinking for a while about modeling typical ecommerce site with ebay-like taxonomy and attributes dependent on a particular product category.

First attempt wa

Answer 1

What if you had different types of categories for different types of products?

Taking the eBay example, we would have Products that can be either Books or TV/Displays.

Books have title and ISBN, and may be in the sci-fi category, or in the erotic category, or in the non-fiction category, or autobiographical category. Or maybe you have a book that is in the non-fiction, autobiographical erotic categories.

Displays have screen resolution and watt-consumption (?), and may be in the flat-screen category, CRT category, or HD category.

From a purely relational point of view, you could maybe model this like so:

[Product]-(1)------(1)-[  Book  ]-(n)------(m)-[ book_category ]
| id    |              | title  |              |  name         |
| price |              | ISBN   |
| ...   |
| ...   |-(1)---(1)-[   display  ]-(n)------(m)-[ display_category ]
                    | resolution |              |  name            |
                    |   watts    |

Instead of modeling attributes dependent on a particular product category, you would have different properties and categories dependent on the type/class of product.

See supertypes & subtypes

Answer 2

I don't claim to have a definitive answer to all of this (it's a rather open-ended question which you should try to break into smaller parts and it depends on your actual requirements, in fact I'm tempted to vote to close it) but I will comment on a few things:

1. I would forget about modelling this on a RDBMS. Faceted search just doesn't work in a relational schema.
2. IMO this is not the right place for code generation. You should design your code so it doesn't change with data changes (I'm not talking about schema changes).
3. Storing metadata / attributes on an Excel spreadsheet seems like a very bad idea. I'd build a UI to edit this, which would be stored on Solr / MongoDB / CouchDB / whatever you choose to manage this.
4. Solr does not "just mirror relational DB". In fact, Solr is completely independent of relational databases. One of the most common cases is dumping data from a RDBMS to Solr (denormalizing data in the process), but Solr is flexible enough to work without any relational data source.
5. Hierarchical faceting in Solr is still an open issue in research. Currently there are two separate approaches being researched (SOLR-64, SOLR-792)