Discussion :

[Erakis]

Bonjour à tous,

J'ai besion de faire des "stress" test sur ma base de données

Pour ce faire, j'ai conçu un programme en C# qui injecte une ligne à chaque 5 minutes et ce durant un période de 4 ans. Dison entre 2006 et 2010.

Voici à quoi ressemble ma table. Elle contient deux champs, soit le premier étant une date et l'autre la valeur. La clé primaire est basé sur la date.

Toutefois, j'aimerais convertir ce champs en type INT et stocker la date à l'aide de UNIX_TIMESTAMP parce que j'ai beaucoup d'opération de temps à faire.

Bref, avec le champs DATETIME, les 4 ans de données s'insert à merveille avec le simulatuer en C#.

Voici un exemple de requête d'injection :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
 
INSERT INTO myTable (sv_Date, sv_Value)
   VALUE ('2006-01-01 00:00:00', 10.0),
   VALUE ('2006-01-01 00:05:00', 80.0)

Maintenant, lorsque j'essais de faire la même chose mais avec un champs INT (clé primaire), j'obtiens un tas d'erreur à cause de doublons !

Exemple de requête d'injection :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
 
INSERT INTO myTable (sv_Date, sv_Value)
   VALUE (UNIXTIME_STAMP ('2006-12-03 00:00:00'), 10.0)
   VALUE (UNIXTIME_STAMP ('2006-12-03 00:05:00'), 80.0)

Donc en résumé, lorque le champs date est au format DATETIME, tout se déroule normalement.

Quand le champs est au format INT et remplie avec UNIX_TIMESTAMP, c'est le bordel ? Je ne comprend pas du tout !

J'ai donc décidé d'ajouter un champs supplémentair à ma table question de faire des tests. J'ai ajouter le champs "sv_RealDate" de type DATETIME.

À présent, le programme C# ajecte de la façon suivante :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
 
INSERT INTO myTable (sv_Date, sv_Value, sv_RealDate)
   VALUE (UNIXTIME_STAMP ('2006-12-03 00:00:00'), 10.0, '2006-12-03 00:00:00')
   VALUE (UNIXTIME_STAMP ('2006-12-03 00:05:00'), 80.0, '2006-12-03 00:05:00')

Maintenant, voici un exemple de quelques lignes bizarre que j'ai vue dans ma table lorsque je cherchais pour les fameux doublons :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
 
SELECT sv_Date,
       sv_Value,
       sv_RealDate,
       FROM_UNIXTIME(sv_Date)
FROM SensorsValues
WHERE sv_Date = UNIX_TIMESTAMP('2006-03-12 02:00:00')
 
  sv_Date    sv_Value       sv_RealDate        sv_RealDateToUnixTime
1142146800, -92.35,    '2006-03-12 02:00:00', '2006-03-12 03:00:00'
1142146800, -76.58,    '2006-03-12 02:05:00', '2006-03-12 03:00:00'
1142146800, -86.05,    '2006-03-12 02:10:00', '2006-03-12 03:00:00'
1142146800,  17.91,    '2006-03-12 02:15:00', '2006-03-12 03:00:00'

La colonne "sv_RealDateTimeToUnixTime" devrait avoir la même valeur que sv_RealDate, eh bien NON ! C'est là que je ne comprend rien à rien. Est-ce que UNIX_TIMESTAMP est buggé ou j'ai manqué une page quelque part ?

Si j'aurais une chance à prendre, je dirais que ça certainnement un rapport avec le DST et la timezone.

Si c'est le cas, alors est-il possible de simplement insérer et récupérer une date sans me soucier du DST ou du timezone. Bref, le même comportement qu'un champs DATETIME ?

Merci pour votre aide.

[CinePhil]

Je pensais à un dépassement de capacité mais cela ne semble pas être le cas d'après tes valeurs.

Explication :
Tu as dit que ta colonne accueillant le UNIX_TIMESTAMP est de type INT.
D'après la doc MySQL, la capacité du type INT est la suivante :

INT 4 -2147483648 2147483647

Le 4 représente le nombre d'octets.

Tes exemples de valeurs qui coincent sont inférieurs au maxi.

Cependant je te donne cette piste et deux idées :
Passe la colonne en INT UNSIGNED, ce qui devrait te donner une capacité de 4 milliards ou alors carrément en BIGINT éventuellement UNSIGNED :

BIGINT 8 -9223372036854775808 9223372036854775807

[Erakis]

Désolé, j'ai omis de mentionné que mon champs est bel et bien un INT UNSIGNED.

D'après ce que j'ai pu comprendre en me promenant sur Google, certains gens disent que c'est à cause de la timezone du serveur.

Le désavantage des UNIX_TIMESTAMP est qu'ils ne sont pas inscrit comme une vulgère date dans une table. Ils sont plus plutot convertient selon la timezone du serveur.

Ce qui à peut-être du sens, puisque qu'avec mon générateur en C#, les doublons se produire toujours dans le bout du mois de mars, donc lorqu'on change la date (Day Saving Time). Donc, dans cette journée, il peut y avoir 12 fois les mêmes 5 minutes puisqu'on recule l'heure de 1 heure !

Ce qui est emmerdant, c'est cette table sert à stocker des valeurs d'acquisition d'automate et que par conséquent, sur notre système on désactive le DST, bref on n'en tient pas compte.

Est-il possible sur MySQL d'insérer des valeurs en UNIX_TIMESTAMP sans tenir compte du DST ???