5

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!

pragmatist1
  • 919
  • 6
  • 16
  • Maybe check out something like [Lucene.NET](http://lucenenet.apache.org/)? – Mike Christensen Feb 05 '14 at 17:21
  • Very nice question. Have you thought about using computed properties (both in the model and in the database)? You can use computed database columns with something like EntityFramework and have them reproduced in the c# class. You can then filter them as if they were static properties. As for the "dynamic properties" part, from what I have seen, it would be much easier to use NoSQL stores for that, since most of them are not typed and allow any amount of properties in any object, even in the same 'table'. Very eager to see what kind of responses you get out of this as I'm interested too. – julealgon Feb 05 '14 at 17:23
  • 1
    @julealgon, The only issue with computed properties is that the car example I gave is just that, an analogy. In reality, some properties might be objects that contain quite complex calculations. It seems like my best option is to tabulate calculated values in the database and update on an as needed basis, since there is emphasis on property searching. Perhaps a mix may be best. – pragmatist1 Feb 06 '14 at 00:08

2 Answers2

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

Kenneth
  • 28,294
  • 6
  • 61
  • 84
0

First Part

Well, you can store variables of the equation that have different value for different cars in the database and write the base-equation as a function or stored-procedure to calculate

Second Part

For this, you should create a dynamic structure for the properties of your class. So you have to create a table (For Ex: PropertyTbl) for properties that keeps PropName &‌ PropType & PropValue and in your class create a list to keeps properties (that are in the database) and a method (and call it each time that the app has be run) to fill that list using PropertyTbl records. In this way you should create a dynamic UI that generate appropriated controls for properties that are in the PropertyTbl.

Third Part

It's more related to the structure of your data. Some data are relational and some are not. See these links to realize that : NoSql vs Relational database http://www.zdnet.com/rdbms-vs-nosql-how-do-you-pick-7000020803/

(Anything else!? Tell in comment! Be successful)

Community
  • 1
  • 1
Seyed Hamed Shams
  • 615
  • 9
  • 22