Ah, ha! I had actually originally planned on doing that but when I read the
primary key could only be an integer I assumed it was a 32 bit integer so I
would need a separate column for the date. But you're right of course and I
see now that as of version 3, I can use 64 bit integers as the primary
Try making your date a REAL and using the Sqlite date and time
functions. You will use extra space for the rowid, the key of the row
and for the b-tree index.
You would expect the indexed rows to be about double the raw text data
since the numbers are 64 bit FP.
Corey Nelson wrote:
> I'm deve
Not really two copies as the integer could be primary key ...
something along the lines of
CREATE TABLE StockName (date INTEGER PRIMARY KEY, price REAL);
Regards,
F.
On Fri, Jul 18, 2008 at 10:03 PM, Jay A. Kreibich <[EMAIL PROTECTED]> wrote:
> On Fri, Jul 18, 2008 at 11:58:16AM -0700, Corey Nel
On Fri, Jul 18, 2008 at 11:58:16AM -0700, Corey Nelson scratched on the wall:
> > sqlite3 Ticks.db ".dump"
> BEGIN TRANSACTION;
> CREATE TABLE StockName (date TEXT UNIQUE ON CONFLICT REPLACE, price REAL);
> I would expect the database file to store a bit of "extra" data but it's
> 2.17 times bigge
Corey Nelson <[EMAIL PROTECTED]>
wrote:
> It didn't take me long to get some test data into an SQLite3 database
> file. But there's a problem, the database file is almost three times
> bigger than storing the information in text files the way I had
> planned.
Well, you can't get something for noth
I'm developing some software that helps with day trading. I need to store
years worth of tick prices. At first I was going to write a library that
would write and read this information to and from files. Then I thought
"don't be silly", this is the sort of thing databases were made for. I have
litt
6 matches
Mail list logo
