On 28 Jan 2012, at 3:31pm, Alexey Pechnikov wrote:
> 2012/1/28 Simon Slavin <slav...@bigfraud.org>:
>> If this database is for longterm use, you're doing the wrong thing. Those
>> should be different rows, not all one huge long row. If it's a one-off
>> hack, then do it and get rid of it before anyone else sees it and shames you.
>
> Why not? Please send link to SQLite documentation instead of any astral
> reasons.
It makes the database schema huge, taking up a lot of memory and a long time to
search. So when you refer to a column called 'tr0997' it has to search a list
of 1000 items in memory before it can work out which column number corresponds
to the column called 'tr0997'. Also, it's very difficult to search and
process. Suppose I want to find 'tr' values are equal to 123. How do I do it ?
If all you need is serial storage just store the values in a long
comma-separated value file, one line per record, with values separated by
commas. This produces a far smaller file which is far faster to write, read
and process.
I'm not sure what your numeric indices are for but a more normal way to store
that would be something like
CREATE TABLE traces (
traceNumber INTEGER NOT NULL,
itemNumber INTEGER,
value FLOAT,
PRIMARY KEY (traceNumber,itemNumber));
INSERT INTO traces (id,itemNumber,value) VALUES (1,0,1)
That means you can store any number of items for each id (not limited to 1000)
and the database engine can find each one directly without having to walk a
long list.
However, as I wrote above, if you're doing what you're doing for a quick hack,
it doesn't matter.
Simon.
_______________________________________________
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
