Merci Fabien pour toutes ces précisions.
FriendFeed utilise des timestamp 
http://bret.appspot.com/entry/how-friendfeed-uses-mysql

On 3 juil, 16:24, Fabien Jakimowicz <[email protected]> wrote:
> 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]
-~----------~----~----~----~------~----~------~--~---

Répondre à