Bonjour,
suite de nos réflexions sur les champs date de la base de données de
SPIP dans le cadre du passage vers PEAR DB.
Pour contenter les principaux SGBD du marché (libre ou commercial), il
faut malheureusement se passer des "vrais" types date, trop différents
de l'un à l'autre, au "profit" de timestamps de type Unix.
Pour ceux qui ne connaissent pas, il s'agit tout simplement d'entiers
représentant le nombre de secondes écoulées depuis minuit le 1er
janvier 1970 (date appelée 'epoch').
L'avantage immédiat est que tous les SGBD savent gérer des entiers
(c'est la moindre des choses), et qu'il est aisé de faire des calculs
sur ces valeurs, que ce soit en SQL ou en PHP.
L'inconvénient majeur est qu'on est ainsi limité à une plage de dates
allant de 1970 à 2038. Je ne vois pas de moyen simple de palier à
cette limite, si ce n'est en utilisant plutôt 3 champs, l'un pour
l'année, l'un pour le mois et l'autre pour le jour, ce qui
compliquerait beaucoup les calculs.
Un autre inconvénient est qu'il est impossible de gérer directement
les dates "imprécises", ce qui pourrait être fait par un champ booléen
supplémentaire.
Avant que l'on se lance dans ces modifications conséquentes, je
voudrais savoir ce que chacun pense de ces différents points, en
apportant éventuellement d'autres solutions.
Quoi qu'il en soit, une classe de manipulation de dates sera
développée pour simplifier cela.
Merci d'avance.
-Nicolas
Nicolas Hoizey wrote:
Bonjour,
suite de nos réflexions sur les champs date de la base de données de
SPIP dans le cadre du passage vers PEAR DB.
Pour contenter les principaux SGBD du marché (libre ou commercial), il
faut malheureusement se passer des "vrais" types date, trop différents
de l'un à l'autre, au "profit" de timestamps de type Unix.
Dans ce cas il vaut mieux utiliser un CHAR(16) avec la syntaxe standard
de MySQL : "2002-05-21 19:08". Ca ne nous dépayse pas trop et ça permet
de garder un spectre large, et des dates imprécises. Enfin les comparaisons
de dates se font avec des comparaisons de chaînes sans aucun problème.
La perte d'efficacité est mineure.
a+
Antoine.
Pour contenter les principaux SGBD du marché (libre ou commercial),
il faut malheureusement se passer des "vrais" types date, trop
différents de l'un à l'autre, au "profit" de timestamps de type
Unix.
Dans ce cas il vaut mieux utiliser un CHAR(16) avec la syntaxe
standard de MySQL : "2002-05-21 19:08". Ca ne nous dépayse pas trop
et ça permet de garder un spectre large, et des dates imprécises.
Là je suis d'accord.
Enfin les comparaisons de dates se font avec des comparaisons de
chaînes sans aucun problème. La perte d'efficacité est mineure.
Par contre, là, il va y avoir des problèmes au niveaux des calculs
actuellement faits dans les requêtes, ne serait-ce que pour les
sélections en fonction de l'age, non ???
-Nicolas
Nicolas Hoizey wrote:
Par contre, là, il va y avoir des problèmes au niveaux des calculs
actuellement faits dans les requêtes, ne serait-ce que pour les
sélections en fonction de l'age, non ???
Si l'âge est une constante, c'est bon :
WHERE date_heure > "2002-05-16 19:08"
où "2002-05-16 19:08" est la valeur calculée en PHP pour un âge de 5 jours.
Par contre, là, il va y avoir des problèmes au niveaux des calculs
Si l'âge est une constante, c'est bon :
WHERE date_heure > "2002-05-16 19:08"
où "2002-05-16 19:08" est la valeur calculée en PHP pour un âge de 5
jours.
Bien vu ! 
C'est le genre de truc qui n'intéresse pas SPIP pour l'instant, ou on
commence à préparer le terrain pour une 2.x avec abstraction DB ?
-Nicolas