Is RavenDB a good fit for this concept?

Question

First, a caveat: I'm rather new to the concepts behind document databases, so this may be an entirely obvious question.

I need to design a system that maintains a deep hierarchical catalog of parts that make up highly-complex products. It will detail the physical components that make up each part - and each part can be components of other parts - all the way up to the final product. Like this:

Widget
 |- Sprocket
 |  |- A4 nut
 |  |- B15 screw
 |  |- Sprocket Backshell
 |- Flange
 |  |- A4 washer
 |  |- Flange Housing
 |- Widget Assembly

Widget in this example could then later be incorporated as a Part underneath some other Product.

Each product may contain tens-of-thousands to hundreds-of-thousands of parts and, each type of component has different, unrelated properties that must be maintained. These properties can include the connections between related parts.

We have a poorly-designed version of this system in place right now, in SQL Server, as a single flat table with about 120 columns and several million records. About 85% of the fields in this table are null. My job is to replace this with something more maintainable and efficient and less error-prone.

Building this efficiently in a relational database would mean normalization - in this case, having one table for each type of part. This would be something of a problem I suspect as there are hundreds of part types, and new part types with their own specific properties are added regularly.

I'd like to use RavenDB for this, as a document database would suit the dynamic nature of the parts, but I don't know if it'd be a good fit, or how I'd implement the system in terms of documents. The products themselves are the root objects, but because of their size I can't afford to store a product as a single document.

Is RavenDB a good fit for this concept? Are there any pointers on how best to represent it in documents?

Answer 1

Erik, whether a document database is a good fit in this situation and what kind of structure would be best depends on what kind of operations you want to do on this data.

You can certainly use RavenDB to persist your parts and products, but to answer the question if it is a good choice, you must answer the following question:

• What kind of queries do you need?
• What is more performance-critical to your system, reads or writes?
• Can you live with eventual consistency?
• Can you take adavantage of features like map/reduce indexes?
• etc.