Meilleure pratique pour stocker la date dans MySQL à partir de PHP
j'ai utilisé le timestamp unix toute ma vie.
Je l'aime parce qu'il est facile à comparer, il est rapide parce que je le stocke comme un entier. Et puisque J'utilise PHP, je peux obtenir n'importe quel format date/heure avec la fonction date() à partir de l'unixtimestamp.
maintenant, certaines personnes disent qu'il est préférable d'utiliser le format DATETIME. Mais à part le nom plus approprié, Je ne vois aucun avantage.
est-il en effet préférable D'utiliser DATETIME, si oui, quels sont les avantages?
Merci.
7 réponses
si vous stockez des dates comme horodateurs Unix dans la base de données, vous vous donnez la lourde charge. Vous devez les convertir au format que vous souhaitez utiliser, vous devez effectuer les calculs entre les plages de dates, vous avez à construire les requêtes pour obtenir des données dans une plage. Cela semble contre-intuitif - sûrement votre "temps de programmeur" est mieux dépensé résoudre de vrais problèmes?
il semble beaucoup mieux pratique de stocker les dates et les heures dans le format approprié que MySQL a disponible, puis utilisez les fonctions de base de données pour créer les requêtes pour les données que vous souhaitez. Le temps que vous perdriez faire toutes les conversions et de mucking sur est énorme par rapport à l'après-midi passé la lecture (et la compréhension) 11.6 MySQL Date et les fonctions de temps
j'ai aussi été un grand fan de l'horodatage unix toute ma vie. Mais je pense que la bonne réponse est: "cela dépend". J'ai récemment fait une base de données de table simple où je voulais seulement énumérer des URLs. Il y aurait un champ de date, mais le champ date est purement pour le tri. I. e par last_crawled. Ce qui veut dire que je n'utiliserai jamais de date intégrée sur ce champ. C'est simplement un moyen facile d'obtenir les entrées les plus anciennes en premier et je ne vais jamais appliquer des fonctions de date à ce champ. Maintenant, j'avais fait un champ date, j'aurais perdu sur deux choses:
- Un champ datetime est deux fois la taille d'un entier
- Tri par un entier est plus rapide (pas sûr à 100% de cela, en attente du résultat de cette question )
Cependant, pour un autre système, j'ai dû stocker des informations transactionnelles. Cela fait en utilisant interne mysql date fonctions possible qui s'est avéré être très utile lorsque nous devions commencer à faire des rapports.
l'un des avantages d'utiliser les types Date/heure MySQL est d'être en mesure d'utiliser plus simplement les fonctions date/heure dans MySQL .
le type DATE a également l'avantage en ce que son seul jour de stockage, mois et année il n'y a donc pas de place perdue ou de la complication de comparaison qu'une seconde depuis le temps d'époque aurait pour les situations où vous ne vous souciez que le jour et non l'heure.
Personnellement, j'ai tendance à utiliser une base de données comme un dump de données de sorte que ces fonctions sont de peu d'intérêt. En PHP j'ai tendance à juste stocker la date dans le format entier pour à peu près les raisons que vous déclarez.
@Smita V, la requête inefficace à laquelle vous vous référez est seulement ainsi parce que vous appliquez votre fonction de conversion incorrectement à chaque rangée de table, où vous devriez l'appliquer à la condition elle-même. Donc au lieu de
select col1,col2,colUnixdatetime from table where From_Unixtime(colUnixdatetime) between wtvdate1 and wtvdate2
, qui convertit chaque ligne sur la table pour la comparer à la date que vous avez. Vous devez utiliser
select col1,col2,colUnixdatetime from table where colUnixdatetime between UNIX_TIMESTAMP(wtvdate1) and UNIX_TIMESTAMP(wtvdate2).
le faire de cette façon utilisera les index de table appropriés.
@treznik a il y a longtemps, je suis passé d'un entier uts à un type de données datetime ou timestamp, pour les raisons mentionnées ci-dessus, en ce qu'elles sont beaucoup plus faciles à lire et à manipuler (je fais beaucoup d'accès direct à la table). Cependant, j'ai récemment commencé à repenser cette approche pour deux raisons:
- il n'y a pas d'emplacement du fuseau horaire stocké, donc vous déduisez le fuseau horaire basé sur votre . Cela peut ou peut ne pas être un problème pour vous.
- Il ignore l'heure d'été. Donc, quand les horloges remontent à 2 heures du matin, vous obtiendrez 1:30 du matin deux fois, et dire 2011-10-30 01:30 ne vous laisse pas savoir cela, alors que 1319938200 le fait. Je ne pense pas qu'il y ait une façon native dans mysql pour stocker la date y compris le fuseau horaire, sauf comme une chaîne de caractères (2011-10-30 01:30 CEST).
j'essaie toujours de trouver la réponse, moi-même.
L'utilisation de database datetime est plus efficace parce que chaque fois que vous avez besoin d'interroger, vous devez appliquer la fonction from_unixtime() pour extraire des données de la colonne unix datetime de la table. L'utilisation de cette fonction dans laquelle la clause ignorera complètement toute utilisation de l'index.
dire que ma requête est:
sélectionner col1,col2,colUnixdatetime à partir du tableau où colUnixdatetime entre wtvdate1 et wtvdate2
j'aurais besoin de courir:
sélectionner col1, col2, colUnixdatetime dans la table where From_Unixtime (colUnixdatetime) between wtvdate1 and wtvdate2
cette requête ci-dessus ignorera complètement tous les index, et bien il n'y a pas d'utilisation des index ici car ils ne seront jamais utilisés car je devrai toujours utiliser une fonction pour obtenir l'heure réelle de la date.
toute fonction intégrée utilisée sur LHS of condition dans une clause where n'utiliserait pas d'index et si vous avez une table ÉNORME, Votre requête prendra plus de temps.
entretien plus facile est un plus. Voir la date réelle quand vous faites:
select * from table where ...
, c'est sympa.
plus facile à comparer, et mysql fournit beaucoup de fonctions de date.