On Fri, Apr 24, 2015 at 12:01 PM, Drago, William @ CSG - NARDA-MITEQ <William.Drago at l-3com.com> wrote: > Since the data is received from the analyzer as an array of > real/imaginary pairs (R,I,R,I,R,I,R,I...), 3202 elements total, > that's how I will blob and store it. This is the simplest way > to add it to the database. It's just one more field along with > all the other data. If I ever need to operate on that trace > data again it's a simple matter of pulling out of the database > and un-blobbing it.
In a case like this, I don't think I've ever come to regret suggesting the use of a serialization library, like protobuf (or cap'n proto or third or avro or ...). When you make your ad-hoc serialization strategy, it works swell for six months, then a new requirement comes downstream and you have to figure out a new format plus how to convert all the old data. If that happens two or three times, you start to get a combinatoric problem which makes it hard to reason about how a change is going to affect existing installs. Most such requirements are for an additional field per array index, which many serialization libraries can support pretty transparently. I don't have any specific recommendations along this front, as usually projects already have one (or two or three) already linked in to cover unrelated cases (reading config files, importing data from another tool, etc). -scott
