-1

I am currently trying to design a database to house production test data. Each unit undergoes the same test sequence (12 tests), voltage, current, and temperature data is collected from many locations at various sample rates during each test run. The goal is to use the data for trending, by test type and parameter, in order to determine whether a unit is "in family" or not.

My first thought is to have a table of 'Units' linked to a table of 'Tests' linked to a table of 'Parameters' which would be linked to the raw data for that particular run Would a relational database be the best way to go about something like this or would I be better off using something like MongoDB for this application?

user3282128
  • 1
  • Mongo is not really a database. If the top-level documents are independent from each other but contain lots of highly-structured data that correlates within a document but not outside of its document, then Mongo might be the answer. For anything else where you want to model non-hierarchical relationships stick to a real relational database. For a better answer, provide some examples of what you want to store. – Jim Garrison Feb 07 '14 at 02:52
  • @JimGarrison "A database is an organized collection of data." (http://en.wikipedia.org/wiki/Database) By this definition, Mongo is most certainly a database. In response to the question, the classic answer applies: it depends. It's really hard to say because we don't know what you'll be doing with your data. For scientific data like this, I might consider shoving everything into a single table with some good indexes if I didn't think extra tables would buy me very much. Think about what kinds of integrity constraints you need to enforce on the data and what kinds of queries you'll be running. – jpmc26 Feb 07 '14 at 02:59
  • Possible duplicate of [Storing time-series data, relational or non?](https://stackoverflow.com/questions/4814167/storing-time-series-data-relational-or-non) – philipxy Jul 06 '19 at 22:09

1 Answers1

1

A traditional RDBMS would still be your default choice. A 'NoSQL' system like MongoDB is something that you would typically use only if a relational database couldn't meet your requirements.

Two typical cases where are relational database might not be workable are:

  • Where data is unstructered, or the structure is not known or can't be guaranteed. A document store or key value store essentially allows you to throw arbitrary data at it, and it will store it.

  • Where there is extremely high concurrency and/or a high mixture of read and write requirements. In this case a traditional relational system might not be able to keep up, because of its requirement to keep data in synch and maintain its integrity.

It's also possible that the amount of data is simply too large, but that implies a lot of data.

In your case, it sounds like the data is highly structured and arriving at a reasonable rate (you won't be receiving data points faster than the physical units can be tested). Additionally, it doesn't sound like there'll be a heavy, parallel load on the system overall (meaning many, many users simultaneously running queries).

In this case you probably want to take advantage of the in-built integrity maintenance mechanisms (typed columns, check constraints and so on), the large amount of documentation and so on that a traditional relational system offers.

As you mention in your question, it will definitely be possible to design a workable schema for your data.

Lindsay Winkler
  • 751
  • 5
  • 13