2009/7/3 Pierre Valade <[email protected]> > > Bonjour à tous, > > J'utilise souvent t.timestamps dans les migrations qui génerent des > datetime (avec mysql). > > Aujourd'hui, j'aimerais vous demander les avantages/inconvénients > d'utiliser des "datetime" plutôt que des "timestamp". > > J'ai l'impression que "timestamp" est plus rapide, mais limité dans le > temps (jusqu'en 2040). > > Qu'en pensez-vous ? Qu'utilisez-vous dans vos applications ? > > Merci par avance pour vos retours, >
concernant mysql, datetime est stocké en 8 octets (4 pour la date, 4 pour l'heure) alors que le timestamp est stocké sur 4 octets représentant le nombre de secondes depuis 1970-01-01 00:00:00. Donc forcemment : - le timestamp est plus limité : 2038-01-09 03:14:07 comme valeur max - le stockage est moins important en timestamp, tant pour les données que les index en dépendant - la vitesse de 'traitement' doit être moins élevée en datetime qu'en timestamp vu la quantité de données à comparer, mais je n'ai aucun bench pour affirmer cela. Je me base juste sur le volume de données à comparer. Pour postgresql, datetime n'existe plus dans la dernière version stable. Mais le stockage des timestamp est fait sur 8 octets ce qui augmente considérablement la limite comparé a mysql. Pour la partie instanciation ruby, aucune différence vu que les 2 types renvoient la même chose. On passe alors par le même code que ce soit un champ datetime ou un timestamp. -- http://fabien.jakimowicz.com --~--~---------~--~----~------------~-------~--~----~ Vous avez reçu ce message, car vous êtes abonné au groupe "Railsfrance" de Google Groups. Pour transmettre des messages à ce groupe, envoyez un e-mail à l'adresse [email protected] Pour résilier votre abonnement envoyez un e-mail à l'adresse [email protected] -~----------~----~----~----~------~----~------~--~---
