Clé primaire & index ...

Le champs timestamp est un peu particulier, car il se met a jour tout seul (quand tu fais une update par exemple).

Pour stocker une date, il faut voir ce que tu fais avec cette date dans ton code. Si tu dois la manipuler, il est, en général, plus facile d'utiliser un timestamp qu'une date, donc dans ce cas tu utilises un champs int. Par contre, si c'est juste pour sauvegarder une date, la tu peux utiliser un champ date.

Tifox a dit:

Le champs timestamp est un peu particulier, car il se met a jour tout seul (quand tu fais une update par exemple).

Cliquez pour agrandir...

Exact, il est fait pour ça, et normalement pas pour autre chose.

Pour stocker une date, il faut voir ce que tu fais avec cette date dans ton code. Si tu dois la manipuler, il est, en général, plus facile d'utiliser un timestamp qu'une date

Cliquez pour agrandir...

Pourquoi ce serait plus facile ?
Quand il voudra faire DATE_ADD(...) ou n'importe quelle autre manipulation de ce champ, il va devoir faire une conversion de type.
Je trouve ça au contraire bien plus compliqué !

je ne sais pas si cela a deja ete dit, mais tu peux aussi creer un index, ou primary key sur une partie d'un champ. Par exemple tu as une date au format 20070503085623.

Et tu fais souvent une recherche sur' les jours, tu peux tres bien creer un index sur
substr(date, 1, par exemple. Tres pratique a savoir. Sinon pour accelerer tes query je te conseille de mettre les clauses qui vont faire tomber le plus de record tout a fait en bas (pour oracle du moin) car la tu te rends compte qu'il lit ton query a l'envers

Bingo a dit:

Pourquoi ce serait plus facile ?
Quand il voudra faire DATE_ADD(...) ou n'importe quelle autre manipulation de ce champ, il va devoir faire une conversion de type.
Je trouve ça au contraire bien plus compliqué !

Cliquez pour agrandir...

C'est pas toujours nécessairement plus facile, ça dépend complètement de l'application, mais j'ai eu le cas ou je récupérais un date de la DB, puis j'avais des tas de test a faire sur cette date, des dates qui dépendaient de cette dates and co, et c'était bien plus facile (à mon sens bien sur) de le faire avec des timestamp que des dates.

Tifox a dit:

Le champs timestamp est un peu particulier, car il se met a jour tout seul (quand tu fais une update par exemple).

Cliquez pour agrandir...

Avec quelle fonction ?

DaBeast a dit:

je ne sais pas si cela a deja ete dit, mais tu peux aussi creer un index, ou primary key sur une partie d'un champ. Par exemple tu as une date au format 20070503085623.

Et tu fais souvent une recherche sur les jours, tu peux tres bien creer un index sur substr(date, 1, par exemple.

Cliquez pour agrandir...

pô bête ça

SkYlEsS a dit:

Avec quelle fonction ?

Cliquez pour agrandir...

Je comprend pas bien la question. Si tu demande comment est mis a jour un champ timestamp, la doc mysql nous dit : "Le type TIMESTAMP est prévu pour stocker automatiquement l'heure courante lors d'une commande INSERT ou UPDATE". Donc dés que tu fais un insert ou un upadte d'une ligne de la table dont un champs est un timestamp, celui-ci est automatiquement mis à jour à la date et heure courante, sans rien devoir lui demander.

Note que j'ai déjà eu des soucis avec des vielle version de mysql (une des première 4.0, donc c'est peut-être valable pour celle d'avant) ou la mise a jour ne se faisait que sur un update, pas sur un insert.

Donc si je veux faire un UPDATE, elle sera d'office mis à jour, et ce même si je ne la nomme pas dans la requête ?

UPDATE table SET id = 'X'; Dans ce cas-ci, s'il existe une colonne de type timestamp pour cette table, sera-t-elle mise à jour ou devrais-je faire ceci :

UPDATE table SET id = 'X' AND date = date;

Normalement, un "UPDATE table SET id = 'X';" met a jour aussi le champs timestamp.

Ok, bah de toute façon je ne ferai que des SELECT une fois le INSERT fait. :-D

SkYlEsS a dit:

Ok, bah de toute façon je ne ferai que des SELECT une fois le INSERT fait. :-D

Cliquez pour agrandir...

UTILISE UN CHAMP DATETIME !!!

Oufti !!!

Bingo a dit:

UTILISE UN CHAMP DATETIME !!!

Oufti !!!

Cliquez pour agrandir...

Occupe 8 octects contre 4 en Timestamp :roll:

SkYlEsS a dit:

Occupe 8 octects contre 4 en Timestamp :roll:

Cliquez pour agrandir...

4 octets... pitié !
Si tu sotckes une date et une heure tu stockes ça dans un champ datetime, point barre.

Chuis radin moi

Mieux vaut alors avoir 2 champs : Date et Time = 6 octets :-D

SkYlEsS a dit:

Chuis radin moi

Mieux vaut alors avoir 2 champs : Date et Time = 6 octets :-D

Cliquez pour agrandir...

Ah ouais, là tu vas loin quand même !

Mais ça c'est un peu la pire des solutions, parce que si tu fais des opérations sur ce champ, tu vas devoir à chaque fois faire additionner ta date et ton heure avant de l'utiliser comme critère !