There is type "binary" (similar to varchar), which is intended for things like images etc.
So you should be able to store values like J nouns (of any shape and type, even boxed, in external binary form) or linear array of scalar type (e.g. list of doubles), and then save and restore accordingly. While you explore this, it would be good to make it into an illustrative example to append to JDB test scripts. The above won't allow any in-DB time series analysis, since the data is opaque that way. An alternative is to store the data relationally, in hope that the inverted representation will already be optimal enough. This would allow some TS logic in queries. There isn't much functional support in existing J-QL, but this use case may present a good opportunity. Do you have a roster of time series analysis you plan to use? E.g. select a fastest growing quantity in a given month, maybe. > From: Bill Harris <[email protected]> > > I have a number of time series I'd like to store and process. > > These time series are not necessarily anchored to fixed points in time > (that is, the absolute timestamps may be in error, but the relative > timestamps should be accurate). Thus it's not necessarily useful to have > a record for each point in a series, for it won't make sense to compare > the value of one series at one time with the value of another series at > that same precise time. > > It will be useful to extract all the time series of one particular type or > other to plot, compare, or process further. > > The best SQLite has to offer seems to be blobs, but each blob has AFAICT > no structure. Now I'm considering JDB. > > From running various labs, I don't see a data type related to a blob in > JDB, but I do see the vr database in the mapped file database lab that > uses jfiles to store comments, and I'm thinking that might be a reasonable > way to go here: create a JDB database record with pertinent measurement > information and links to the associated time series for that measurement > (there may be ~20 parallel time series per measurement). I'm guessing > that I can program a bit of structure into that jfile without too much > effort, having used jfiles years ago, but I haven't put them and JDB > together. > > Does that seem like a reasonable use of JDB, or does anyone have a better > idea? I think I'll end up with between 50 and several hundred > measurements -- more than I want to manage as separate files but not > enormous, either. Then again, there is the possibility that this would > expand into the several thousand or more records before I'm done. > > Thanks, > > Bill > > ---------------------------------------------------------------------- > For information about J forums see http://www.jsoftware.com/forums.htm ---------------------------------------------------------------------- For information about J forums see http://www.jsoftware.com/forums.htm
