How do I make an object with modular, searchable fields in database in C#? [closed]

Question

I wanted to ask a design question on how best to structure a class for objects that I would like to have searchable fields, including fields that are objects - but also modular, in a sense that fields can be added based on new entries in a DB. Let me clarify:

Suppose I have an object type, Car. The car has properties like make, model, color, top speed which can be represented by simple types like strings and doubles, etc.. but it also may contain more complex information, such a property with type CarPowerProfile (a separate object), which holds an equation that describes the power output of the vehicle as a function of throttle. Or perhaps other sub-objects.

My question breaks down to the following:

What is the best way to design such a class, so that I can search a database, not only for simple properties like color, make and model, but for say "find me a car that is blue and has between 70% and 90% power output for 30% throttle"? The problem is, I need to object that performs the calculation to get that information, and the database only stores the coefficients for the equation.

Also, say someone wanted to add a property to the object (in addition to hardcoded "base properties"), how is this best implemented so that the new property is both in the database and the loaded object? And finally, is this problem best suited for a relational or non relational database, keeping in mind that this will be a standalone application that will synchronize with a web service.

I realize I am asking a lot, but I am not looking for code handouts but more for how to design a solution - which is why I am using words and not code to describe the issue. I come from a background of numerical computing, and this type of software design is foreign to me. I am more interested in if there are design patterns for things like this (or similar), or maybe a different approach because I'm tackling the problem incorrectly.

Thanks!

Answer 1

There are a few ways you can go about this and they basically come down whether you optimize for reading or writing.

If you optimize for writing by only saving the core values in the database, querying becomes more expensive as you will have to load all the objects from the DB and then do calculations to filter them.

On the other hand if you optimize for reading by storing the calculated values in the database, writing will be slower because before each write you will have to recalculate all the values and then write all the correct values to the database.

In the case you are explaining I would try to find a balance. Store all the core values in the database and also the few calculated ones where you expect the most queries to run. Then you can filter on these and then further filter them on the application server. If you do it right you'll have a good balance.

If you're using an ORM such as NHibernate or EntityFramework, you can easily query over multiple tables using LINQ.

As for whether you should go for relational or not, if you want to have a flexible schema then a NoSQL solution is probably better suited. But there are also a few disadvantages to NoSQL. You'll have to apply the same trade-off on (de)normalization as with your calculated properties, keeping in mind that this is very important in a NoSQL database.

A NoSQL solution like RavenDB, which is especially optimized for .NET lets you define Map Reduce queries which provide very fast query access, so I would have a look at that