Hi, You have an interesting problem .... hm. >From what you say - have a look at Martin Fowler's Quantity pattern
READING - any kind of Cron derivative which will execute readings and send them to your EventStorage STORAGE - the document database seems to make more sense - an alternative solution is EvenSourcing this will take care of measurement storage and when you will know what kind of reports do you need you'll have just to replay them Hope it helps :) On Mar 11, 4:25 am, Børgi <[email protected]> wrote: > Hello everybody! > > I got green lights for a new project and now I'm pondering with > different approaches for my database schema. > > The problem domain is the following: > > 1) We want to store the measurement output of any number of sensors. > > 2) Each measurement has to include the information when it was > measured and when it was stored. > > 3) A measurement could produce multiple data sets, for example a tilt > meter could produce one result per 10 meters of a tunnel at a time. > > 4) Each type of sensor provides different measurement data (eg, X, Y, > H, temperature, tilt, ...), so we can not assume a common data > structure. > > 5) We think that there will be a maximum of 10 sensor types. > > 6) Writing data doesn't have to be blazingly fast, but it should be > possible to write about 40 sets of data per second > > 7) The database could collect data for a period of over 10 years, so > there is a chance that it has to master data of well over 500GB > > The idea most tempting for me is the relational database way: > > TABLE SensorType (Contains the different types of sensors with all > important information) > TABLE SensorA (Inventory of sensors of type A) > TABLE MeasurementSensorA (All measurements of all sensors of type A) > TABLE SensorB > TABLE MeasurementSensorB > ... > > So I would create tables 2 & 3 for every type of sensor. > But what happens if I want to aggregate the output of different sensor > types for reporting purposes? > Will the user have to wait long for his/her results, beacuse of all > the Joins that will have to be performed? > > Now there are other possible approaches. > What about XML data in Microsoft SQL Server? Would it be better to > have only one Measurement table and save the output of a measurement > in XML format? > Or what about CouchDB, MongoDB, RavenDB,... As I don't know which data > I will have to store in the future, this also seems to be a viable > alternative. > > Do you have any suggestions? How would you design it? > > Thanks a lot! > Sebastian -- You received this message because you are subscribed to the Google Groups "nhusers" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/nhusers?hl=en.
