Database design to manage data from Serial Port?

I'm writing codes to capture Serial Port data (e.g. micrometer) and do the following

1. real time display and graphing
2. delete/modify/replace existing data by focus and re-measurement,
3. save data somewhere for additional statistical analysis (e.g. in Excel). So out put as .csv is also an option

Because each measurement may capture hundreds to thousands of data (measurement points), I'm not sure how shall go about to design my database - shall I create a new row for each data received, or shall I push all data into an array and store as a super long string separated by a comma into the database? For such application, do I need Server 2008 or would Server 2008 Express will be sufficient. What are their pros/cons in terms of performance?

Is it poss开发者_运维技巧ible to create such as application where client won't need to install sql server?

To answer your last question first, look at SQLite because it is free open source, and I'm pretty sure their license is null. Plus nothing to install for your users. SQLite can be compiled with your code.

To answer your primary question, I would encourage using a database only if it really makes sense. Are you going to be running queries against the data, or are you just looking to store and retrieve entries by some sort of identifier? I would discourage storing it as a super long comma separated string, but instead look into the BLOB type. With BLOBs, you can put datatypes into the database so you can easily get them back out, plus I believe it is much more efficient that way. I would only suggest using TEXT type if you need to do some sort of text query on it. For example fulltext searches

If you decide that the giant string approach makes sense for your application, you would probably just be better off using text files. Relational databases provide benefit only when your data is structured. If you go with a database it should be because you are storing discreet values in rows and columns.

An out of process database strikes me as a mismatch for this project. Have you considered SQLite or some other compile-or-link in solution? You'll probably get faster throughput of those large measurement vectors with something that runs in process.

What do you want (or what do you think you want) a relational database for?

Based on the simple requirements you expressed here (and assuming there are none other), I would suggest flat files (this could be either plain text, one sample per line, or binary). But I really don't think I have enough information to make a decision on your behalf. Some key questions are:

1. Do you need to share the data with others, who uses the data, where, over the network? (this will dictate the format you save the data in and a few other things)
2. How much data do you need to store, how fast does it get measured and over what period of time to measure and store this data? (this will tell you whether to use compression, or some other space saving scheme or not, this will also give you pointers to resource requirements)
3. How easily retrievable does it need to be? (this will give pointers as to what data management you need: how to name files, where to store them...)
4. What sort of analysis do you need to do on it? (do you want to analyse several files together, just one file, data from a given day, data for a given port... ?)

... and many more such questions.

Depending on answers to these questions you might be happy with an old 386 computer, or you might need a modern 8-core.