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
On May 30, 2006, at 3:05 AM, Noel Frankinet wrote:
Hello Rusty,
Exactly what I was looking for
I've seen the PRAGMA TEMP_STORE to create a memory table.
Do you think I can join a memory table and a disk based one ?
Anyway, thank a lot
Best wishes
Of course you can do that.
Rusty
--
Rusty C
Rusty Conover wrote:
Using a temporary table seems to be the best way when you have lots
of keys. Of course there is a tradeoff point, such as for 1 or 2
rows a temporary table is overkill. Also it depends on if you're
temporary table is being stored in memory or on the disk, check the
On May 30, 2006, at 1:36 AM, Noel Frankinet wrote:
Hello All,
since nobody has answered my last question, I'll try to rephrase it :
How do you select record you have the keys (and I mean a lot of keys)
I know
SELECT .. WHERE rowid=
SELECT .. WHERE rowid IN (something like that)
SELECT ... WHAR
Hello All,
since nobody has answered my last question, I'll try to rephrase it :
How do you select record you have the keys (and I mean a lot of keys)
I know
SELECT .. WHERE rowid=
SELECT .. WHERE rowid IN (something like that)
SELECT ... WHARE rowid BETWEEN ...
Is there another way, does a temp
Hello All,
Still trying to figure out the best way to index on top of sqlite (for
spatial indeex).
Lets say the the external index gives me a bunch of rowid, what would be
the correct way to send that to sqlite ?
(My sql levelis rather low)
Should I bypass the sqlparser or is there an efficent
11 matches
Mail list logo
