On 24 Aug 2011, at 12:39pm, LiranR wrote: > ID (PK) | TimeStamp (PK) | data | data | and data ... > ------------------------------------------------------------- > 1 | 1000001 | float | float | float > 2 | 1000002 | float | float | float > 3 | 3 | float | float | float > 4 | 4 | float | float | float > ... | ... | float | float | float
The schema above is a little strange. You can't have two primary keys for the same table. So either A) your ID column is the primary key, the TimeStamp column may or may not be another key B) your TimeStamp column is the primary key, the ID column may or may not be another key C) you have a primary key of (id,TimeStamp) which would be very unusual > As you can see, the table is already has been filled, and its the second > time entering data. > the next row to update is row 3, which will be have TimeStamp 1000003. > Because the face that time stamp is always rising, i can't leave there only > the number 3. If you are concerned about the (small amount of) extra work involved in changing a primary key column, I think you can just have your ID column as the primary key. > Also, I have to use TimeStamp as PK (Primary Key) because of > the fact that when i want to read data from the table i search the table by > timestamp. No, that's not what primary keys are for at all. You can search a SQL table using any value you like. If you want to make the search fast, make an INDEX on the column. CREATE INDEX myTableTimeStamp ON myTable (TimeStamp) Simon. _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
