> Si tes dates sont stockées sous forme classique (2004-06-31 19:53:21)
Marche pas avec le passage heure d'été/hiver. Il faut un "truc" supplémentaire. Par exemple stocker les heures en GMT. Puis c'est a toi de prendre en compte les locales. C'est lourd. PostgreSQL fait ça tout seul. De plus tu ne peux pas faire de différence de date avec SQLite (par exemple).
> Si tu lis la news et les liens tu verras que justement depuis cette version il y a un typage simple mis en oeuvre pour distinguer int/float/text/blob
Faut aller lire le site. Il n'y a pas de vrai typage. Les données restent stockées en string.
Vas lire le site attentivement.
> Quelqu'un peut me rappeler en quoi un SGBD doit fournir des fonctions de traitement de date pour avoir le droit d'être un "système de gestion de base de données" ?
Stocker des données et ne pas pouvoir faire de traitement (par exemple soustraction) n'est "pas top".
[^] # Re: lire attentivement
Posté par 007 . En réponse à la dépêche Ça bouge du côté de SQLite !. Évalué à 0.
Marche pas avec le passage heure d'été/hiver. Il faut un "truc" supplémentaire. Par exemple stocker les heures en GMT. Puis c'est a toi de prendre en compte les locales. C'est lourd. PostgreSQL fait ça tout seul. De plus tu ne peux pas faire de différence de date avec SQLite (par exemple).
> Si tu lis la news et les liens tu verras que justement depuis cette version il y a un typage simple mis en oeuvre pour distinguer int/float/text/blob
Faut aller lire le site. Il n'y a pas de vrai typage. Les données restent stockées en string.
Vas lire le site attentivement.
> Quelqu'un peut me rappeler en quoi un SGBD doit fournir des fonctions de traitement de date pour avoir le droit d'être un "système de gestion de base de données" ?
Stocker des données et ne pas pouvoir faire de traitement (par exemple soustraction) n'est "pas top".