[sqlite] Best way to handle time slicing of SQL data.

Hi, I'm wanting to store data in a way such that I can choose a time in the past and view records as they were at that dateTime. Therefore (in my mind), all updates are really inserts with a timestamp. Ids are suddenly no longer primary keys, as many records can have the same id, but a new

[sqlite] Best way to handle time slicing of SQL data.

On 2 Jun 2015, at 12:34pm, Richard Warburton wrote: > I'm wanting to store data in a way such that I can choose a time in the > past and view records as they were at that dateTime. Therefore (in my > mind), all updates are really inserts with a timestamp. Ids are suddenly > no longer primary

[sqlite] Best way to handle time slicing of SQL data.

ese fields need to be present in every index and queried in every select. -Urspr?ngliche Nachricht- Von: Richard Warburton [mailto:richard at skagerraksoftware.com] Gesendet: Dienstag, 02. Juni 2015 13:34 An: sqlite-users at mailinglists.sqlite.org Betreff: [sqlite] Best way to handle ti

[sqlite] Best way to handle time slicing of SQL data.

On Tue, Jun 2, 2015 at 7:34 AM, Richard Warburton < richard at skagerraksoftware.com> wrote: > 1) Do I need UID? I'm currently using it to ensure a unique Id for when > the user is creating a new entry. This however means two operations, an > Insert, then an Update to set the record's Id to

[sqlite] Best way to handle time slicing of SQL data.

On 6/2/2015 7:34 AM, Richard Warburton wrote: > 2) Can I auto fill Id to UID on insert instead of having to do two > operations? Yes, with an AFTER INSERT trigger -- Igor Tandetnik

[sqlite] Best way to handle time slicing of SQL data.

On Tue, Jun 2, 2015 at 4:34 AM, Richard Warburton < richard at skagerraksoftware.com> wrote: > Hi, > > I'm wanting to store data in a way such that I can choose a time in the > past and view records as they were at that dateTime. Therefore (in my > mind), all updates are really inserts with a