Hi,
We aren't storing first_seen in every row. Each incident is something
like
Date_Time_of_update_in_epoch_secs1 unique_incident_number information about the incident>
Date_Time_of_update_in_epoch_secs2 unique_incident_number information about the incident>
Date_Time_of_update_in_epoch_secs3
Why are you storing first_seen in every record? To avoid searching for it
when reports are generated?
On Sat, Aug 31, 2019 at 6:24 AM Rob Willett
wrote:
> Hi,
>
> We have a very similar system that captures traffic incident information
> such as accidents, roadworks, traffic jams and sends
On Sat, Aug 31, 2019 at 12:24 PM Rob Willett
wrote:
> 5. SQLite seems to be able to do anything we want it to. [...]
> Other people seem worried about the 'lack' of some datatypes, we do
> masses of data and date conversations as needed and it's never been a
> speed issue or any issue.
(since
Hi,
We have a very similar system that captures traffic incident information
such as accidents, roadworks, traffic jams and sends personalised
information to drivers based on their routes.
We realised after a few years that our original design for the database
was inefficient as we had a
On Fri, Aug 30, 2019 at 3:35 PM Keith Medcalf wrote:
> Seems fine, other than that event.first_seen and event.last_seen can be NULL,
> in which case that field will never be updated. So while you may claim that
> you never store NULL in those fields, doing so will cause non-workage due to
>
On Friday, 30 August, 2019 14:45, Random Coder wrote:
>CREATE TABLE IF NOT EXISTS
>event(
>event_id TEXT PRIMARY KEY,
>first_seen INTEGER,
>last_seen INTEGER
>) WITHOUT ROWID;
So first_seen and last_seen are permitted to be NULL?
>
6 matches
Mail list logo
