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 pers
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 sin
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
> in
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?
>INS
First off, if this sort of "code review" style question is
inappropriate for this list, please feel free to reply to me directly
and tell me to stop, and I'll know to not do this again.
That said, I have a question on the use of SQLite. At the risk of
falling into the XY problem, I'll give some d
7 matches
Mail list logo
