On 3/16/18, Jens Alfke wrote:
> Yes, the solution involves creating a table as you described, but the table
> is derived from and dependent on the original JSON data, and needs to be
> kept up to date as that data changes. Triggers are the best way I know of to
> do that, but I'm open to other id
> On Mar 16, 2018, at 1:24 AM, Hick Gunter wrote:
>
> So in your application you don't care about when a temperature was measured?
> Creating a table temps (patient_id, timestamp, temperature) with an index on
> (timestamp,temperature) would yield a fast way to access patients with
> elevate
True, I mean in case there were multiple dimensions. I should write down
hidden thinking processes more.
On Fri, Mar 16, 2018 at 9:58 AM Simon Slavin wrote:
> On 16 Mar 2018, at 8:38am, Wout Mertens wrote:
>
> > It seems to me that the only real option is to maintain a derived table,
> > the ta
On 16 Mar 2018, at 8:38am, Wout Mertens wrote:
> It seems to me that the only real option is to maintain a derived table,
> the table could even be R*TREE to allow range queries.
You can always do range queries on tables in SQLite. Not sure what you mean by
the above.
Simon.
_
I have the same problem but luckily O(n) performance is fast enough for me
right now.
It seems to me that the only real option is to maintain a derived table,
the table could even be R*TREE to allow range queries.
Triggers seem to be the accepted way to derive tables, but I'm a little
afraid of t
So in your application you don't care about when a temperature was measured?
Creating a table temps (patient_id, timestamp, temperature) with an index on
(timestamp,temperature) would yield a fast way to access patients with elevated
temperatures within a time frame.
Other than that, using trig
6 matches
Mail list logo
