Lad mig omskrive tingene fra kommentarer til mit svar. Du vil bruge timestamp type i stedet for integer simpelthen fordi det er præcis, hvad det er designet til. Udfører manuelle konverteringer mellem tidsstempelheltal og timestamp genstande er bare en smerte, og du vinder intet. Og du får brug for det til sidst til mere komplekse dato- og tidsbaserede forespørgsler.
For at besvare et spørgsmål om paginering. Du laver blot en forespørgsel
SELECT *
FROM table_name
WHERE created < lastTimestamp
ORDER BY created DESC
LIMIT 30
Hvis det er den første forespørgsel, indstiller du sige lastTimestamp = '3000-01-01' . Ellers indstiller du lastTimestamp = last_query.last_row.created .
Optimering
Bemærk, at hvis tabellen er stor, så ORDER BY created DESC er muligvis ikke effektiv (især hvis den kaldes parallelt med forskellige områder). I dette tilfælde kan du bruge bevægelige "tidsvinduer", for eksempel:
SELECT *
FROM table_name
WHERE
created < lastTimestamp
AND created >= lastTimestamp - interval '1 day'
1 day intervallet vælges vilkårligt (indstil det til dine behov). Du kan også sortere resultater i appen.
Hvis resultaterne ikke er tomme, opdaterer du (i din app)
lastTimestamp = last_query.last_row.created
(forudsat at du har sorteret, ellers tager du min(last_query.row.created) )
Hvis resultaterne er tomme, gentager du forespørgslen med lastTimestamp = lastTimestamp - interval '1 day' indtil du henter noget. Du skal også stoppe hvis lastTimestamp bliver for lavt, dvs. når det er lavere end ethvert andet tidsstempel i tabellen (som skal forudhentes).
Alt dette er under nogle forudsætninger for indsættelser:
new_row.created >= any_row.createdognew_row.created ~ current_time- Distributionen af
new_row.createder mere eller mindre ensartet
Antagelse 1 sikrer, at paginering resulterer i ensartede data, mens antagelse 2 kun er nødvendig for standard 3000-01-01 dato. Antagelse 3 er at sikre, at du ikke har store tomme huller, når du skal udstede mange tomme forespørgsler.