[SQL] hoe data uit tabellen combineren (geen join?)

[honda4life]

Hallo iedereen,

In mijn vrije tijd durf ik wel eens aan het programmeren te slagen.
Momenteel log ik data naar een sqlite database.
Deze data wordt in batch naar een server verzonden per 30.
De primary key van deze data is een timestamp.
Nu wil ik op een efficiënte manier de status van deze updates bijhouden:
Aan elke rij een updatestatus toevoegen lijkt me niet de ideale manier.
Daarom heb ik een tweede tabel aangemaakt met de start- en eindtijd van de data in de batch. met de updatestatus.
Hoe combineer ik deze data met een query?

Om een voorbeeld te geven:

Verzamelde data:

timestamp	value
1-1-2012	999
2-1-2012	888
...-1-2012	...

Na succesvolle upload van de batch (stel eerste 2 waarden), krijg ik een response code van de server.
Deze stockeer ik als volgt:

firsttime	lasttime	response
1-1-2012	2-1-2012	OK

Nu wil ik alle gegevens uit de database halen die niet de response OK hebben, wat er dus moet gebeuren is controleren of de timestamp ergens tussen first- en lasttime voorkomt, en de status joinen.
(uiteindelijk wil ik de data die niet OK zijn.)

Ik vermoed dat dit niet zo heel moeilijk is, maar mijn SQL kennis is te beperkt om zonder gefoefel te programmeren.

Bedankt!

[winkbrace]

Allereerst moet ik kwijt dat ik nog nooit een timestamp als primary key ben tegengekomen. Ik kan niet zo snel bedenken waarom het niet mag, maar het is hoogst ongebruikelijk.

En wat je hier nodig hebt is een non equi join:

SQL:

select t.*
from   table t
join   valid_times v on t.timestamp not between v.firsttime and v.lasttime

[honda4life]

Ik zie niet in waarom een timestamp geen primary key kan zijn, vermits deze écht wel uniek is in mijn geval.
Straks FF testen en, eerst wet informatie opzoeken over jouw suggestie

[winkbrace]

Ja, je hebt gelijk. Als het veld nooit geupdate kan worden, mag je het uiteraard als primary key gebruiken.

Overigens gebruik ik zelf wel vaak een extra kolom in mijn tabellen met een voortgangsstatus of log_timestamp oid. De simpelste oplossing is namelijk meestal de beste. Door in dit geval bij elke batch van 30 ook even een current_timestamp in een log_timestamp kolom toe te voegen, ben je volgens mij efficienter bezig dan een extra sql call naar een andere tabel, die je later weer moet joinen.

[Gomez12]

Het nadeel van een timestamp als primary key is dat die volledig afhankelijk is van randfactoren.

Als je een sneller computer koopt dan heb je een risico dat je doublures krijgt.
Gaat je systeemtijd veranderen (bijv doordat je hem in een netwerk hangt of doordat je een NTP-client eraan koppelt) dan ga je doublures krijgen.
Maar ook al hang je bijv een ntp-client eraan en gaat je inet verbinding er voor een dag uit (no NTP-updates) dan heb je morgen een grote sprong NTP-sprong.

Tijd is simpelweg op computers niet accuraat, en het hoeft nu allemaal geen probleem te zijn, maar over een jaar of een half jaar heb je opeens een programma wat "raar" doet terwijl het al een half jaar heeft gewerkt.