---

Det er ikke så lang tid siden jeg har opgraderet til MySQL v4.1 og jeg har
lige opdaget, at timestamp formatet er ændret. Tidligere hed det
"yyyymmddHHMMSS" mens det nu hedder "yyyy-mm-dd HH:MM:SS". Dvs. tidligere
var det et heltal mens det nu er en streng.

Jeg kan ikke helt se det logiske i dette, da det tidligere var langt nemmere
at søge i tidsintervaller - f.eks. "SELECT blaaa WHERE
timestamp>20030106000000 and timestamp<20040304120000" - nu skal man istedet
gå en omvej for at få det samme reultat. Endvidere synes jeg da også, at det
må være langsommere at søge på (en streng) fremfor tal?

Er den eneste måde at omgå dette på ved at oprette et nyt database felt og
så manuelt indsætte datoen som et heltal (og undgå timestamp funktionen i
MySQL)?

---

On Sun, 06 Jun 2004 20:43:53 +0200, Joe Doe wrote:

> Jeg kan ikke helt se det logiske i dette, da det tidligere var langt
> nemmere at søge i tidsintervaller - f.eks. "SELECT blaaa WHERE
> timestamp>20030106000000 and timestamp<20040304120000"

Et sådant query vil stadig fungere. Der er flere forskellige måder at
angive tidsværdier, når man vil kommunikere sådanne til MySQL - se
MySQLs manual.

> Endvidere synes jeg da også, at det må være langsommere at søge på
> (en streng) fremfor tal?

Hvordan en værdi præsenteres eller indtastes behøver ikke at have noget
at gøre med, hvordan DBMSet gemmer værdien. Ud fra manualen at dømme,
gemmer MySQL internt TIMESTAMP-værdier som heltal (unix timestamps).

> Er den eneste måde at omgå dette på ved at oprette et nyt database
> felt og så manuelt indsætte datoen som et heltal (og undgå timestamp
> funktionen i MySQL)?

Hvis databasen har nogle relevante typer til dato/tid værdier, så er det
smart at benytte en af disse, bl.a. af hensyn til korrekthed. (Mht.
dato/tid-værdier, så er lige netop MySQL ikke særlig god til at sikre
korrekthed.)

Hvis du er interesseret i datoer (ikke tidspunkter), hvorfor så ikke
benytte MySQL's DATE type?

--
Greetings from Troels Arvin, Copenhagen, Denmark