Thank you for your input, masquerade! The Quantity pattern would make sense in this project, I will have to look into that.
You are right, event sourcing would be great. Why didn't I think of it myself! Did you use this technique in production code already? Again the question: which database would you use for your events? MS SQL with XML or NoSQL - the latter I guess? Thanks! On 11 Mrz., 15:53, masquerade2ruslan <[email protected]> wrote: > 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.
