Pour des raisons trop obscures pour entrer dans, j'ai une représentation millisecond d'une heure spécifique et j'ai une base de données MySQL remplie de horodatage MySQL et je suis curieux s'il est possible de faire des comparaisons indigènes dans SQL tels que < Code> Sélectionnez * à partir de MyTable où TIME_STAMP_COLUMN> 1264665600000; ou quelque chose sur ces lignes.
J'ai exécuté des tests et les résultats sont assez étranges. Il ne se plaint pas mais retourne la ligne qui ne correspond pas aux critères.
Merci d'avance.
[modifier] OK Si vous utilisez millisecondes dans MySQL est un non-starter, quelle est la meilleure façon de comparer les dates, en supposant que je commence à Millis et à Java.
4 Réponses :
Apparemment Il s'agit d'un bug connu: Bug 8523 . Voir Une fois un horodatage (millisecondes) ...
En justice, MySQL a effectivement fourni un moyen de retenir Milli et micro secondes dans un champ décimal
décimal (17,3) , et c'est aussi interrogable comme si c'était un horodatage Mais pourquoi n'est-il pas possible de stocker dans aDateTime ouhorodatage champ?
NO, TimeStamp et les colonnes DateTime ne stockent pas malheureusement à la précision de millisecondes. Un travail autour de ceci est d'utiliser une colonne Bigint et d'avoir votre horodatage avec le nombre approprié de places de millisecondes, c'est-à-dire. 1264808431000. Malheureusement, cela signifie que toute logique de comparaison dans votre application ou dans MySQL devra être sur une base de Bigint.
Je ne trouve pas cela un inconvénient du tout, personnellement. Les entiers sont de manière plus simple et plus uniforme entre les bases de données et les couches d'accès aux données que le gâchis des types de date. Ce n'est peut-être pas idéologiquement pur, mais il n'y a pas d'inconvénient pratique; C'est Int / Bigint Timeestamps pour moi, à chaque fois.
@bobince - Je trouve cela un peu difficile à manier, et il est plus difficile d'utiliser certaines des fonctions de date spécifiques à la SMDBMS. D'autre part, vous pouvez parfois enregistrer un octet ou deux sur un enregistrement à l'aide d'INTS. C'est une décision assez contextuelle.
Oui, je ne le fais pas pour des économies de stockage, je le fais pour la prévisibilité: ne pas avoir à se soucier de la dateformats et des fuseaux horaires qui est quelque chose que je considère comme une partie de la couche d'interface utilisateur et non tout ce que je veux n'importe quoi près de mon magasin de données Backend. Je considère qu'il est vraiment idiot de convertir mon horodatage en une chaîne juste pour que MySQL puisse le convertir en horodatage pour le stockage (uniquement avec un fuseau horaire local loué).
Les fonctions de la date SQL pourraient être utiles, mais dans la pratique, je devrais très rarement faire des requêtes comme une heure (T) = 12 qui ne peut pas être faite aussi facilement avec des INT, et dans la pratique car ces fonctions défaitent l'indexation, il n'y a pas de gagner de l'utiliser directement contre la colonne.
Vous n'obtenez pas de précision de millisecond, mais à en juger par les zéros à la fin de votre exemple, vous ne pouvez pas en avoir besoin.
Utilisez de_unixtime Pour convertir un horodatage UNIX en horodatage MySQL. On dirait que vous avez des millisecondes depuis l'époque Unix, alors divisez-les de 1000 pour convertir: P>
SELECT * FROM myTable WHERE time_stamp_column > FROM_UNIXTIME(1264665600000/1000);
Non Non ... Tu as raison, je m'en fiche de la précision de milliseconde, je peux même passer au nombre déjà réduit de 3 ordres de grandeur ... je pense que cela fonctionnera.
Si vous voulez cette fonctionnalité dans MySQL, n'hésitez pas à laisser l'équipe MySQL Dev Sachez en votant pour celui-ci sur Official MySQL Worklog: