> -----Original Message----- > From: sqlite-users-bounces at mailinglists.sqlite.org [mailto:sqlite- > users-bounces at mailinglists.sqlite.org] On Behalf Of Scott Hess > Sent: Friday, April 24, 2015 3:19 PM > To: General Discussion of SQLite Database > Subject: Re: [sqlite] Thoughts on storing arrays of complex numbers > (Solved) > > 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.
So, serialize the complex array data then store it in SQLite as a blob? I'm working in C# which has built-in support for serialization, do I still need a third party library? Other than writing some objects to disk in Java quite a few years ago, I have little experience with serialization, sorry for the ignorance. -- Bill Drago Senior Engineer L3 Narda-MITEQ 435 Moreland Road Hauppauge, NY 11788 631-272-5947 / William.Drago at L-3COM.com CONFIDENTIALITY, EXPORT CONTROL AND DISCLAIMER NOTE:This e-mail and any attachments are solely for the use of the addressee and may contain information that is privileged or confidential. Any disclosure, use or distribution of the information contained herein is prohibited. In the event this e-mail contains technical data within the definition of the International Traffic in Arms Regulations or Export Administration Regulations, it is subject to the export control laws of the U.S.Government. The recipient should check this e-mail and any attachments for the presence of viruses as L-3 does not accept any liability associated with the transmission of this e-mail. If you have received this communication in error, please notify the sender by reply e-mail and immediately delete this message and any attachments.
