ALTER TABLE sujet ADD tmpswap DATETIME;
UPDATE sujet SET tmpswap = FROM_UNIXTIME(ancien);
ALTER TABLE sujet DROP ancien;
ALTER TABLE sujet CHANGE tmpswap ancien DATETIME;

(sujet : nom de la table ; ancien : nom de la colonne initialement en (big)int)

ALTER TABLE sujet ADD tmpswap DATE;
UPDATE sujet SET tmpswap = STR_TO_DATE(ancien, '%d/%m/%Y');
ALTER TABLE sujet DROP ancien;
ALTER TABLE sujet CHANGE tmpswap ancien DATE;

(sujet : nom de la table ; ancien : nom de la colonne initialement en varchar)

Pourquoi utiliser le type DATE ?

• pour simplifier toute manipulation sur les dates : vous pouvez ainsi nativement utiliser toutes les fonctions date du SGBD sans avoir à d'abord reconvertir [le format de] la date
• le format interne (us) prévu permet nativement un tri (lexicographique) correct
• le formatage au format fr (ou autres) ne justifie pas une colonne en VARCHAR : tous les langages ou même les SGBD (DATE_FORMAT pour MySQL) permettent facilement la conversion. Et quid du jour où votre site devra être internationalisé ?
• le SGBD s'assure que la date est un minimum correct, toute erreur à l'insertion/modification est minimisée. Au contraire, avec un varchar, si le format est incorrect, ça peut être catastrophique suivant l'importance des données. MySQL avec un sql_mode comprenant les valeurs NO_ZERO_IN_DATE (interdit des composantes de date à 0) et NO_ZERO_DATE (interdit les dates "zéro" 0000-00-00 obtenues par défaut dans des cas +/- foireux) et sans ALLOW_INVALID_DATES assurera une cohérence des plus strictes.

On peut aisément remplacer un CASE comme celui-ci :

SELECT CASE <in>
    WHEN 'FT' THEN 'Fiche Technique'
    WHEN 'PV' THEN 'Procès Verbal'
    WHEN 'NF' THEN 'Norme'
    ELSE 'Valeur par défaut'
END;

Par :

COALESCE(
    ELT(
        FIELD(<in>, 'FT', 'PV', 'NF'),
        'Fiche Technique', 'Procès Verbal', 'Norme'
    ),
    'valeur par défaut'
)

C'est l'"équivalent" PHP de :

Par contre : ça revient éventuellement à "réinventer" le type ENUM

SET FOREIGN_KEY_CHECKS=0;
 
-- les différentes opérations sql à exécuter en ignorant les clés étrangères
 
SET FOREIGN_KEY_CHECKS=1;

Déplacé sur http://www.julp.fr/blog/posts/5-les-timezones-et-comment-regler-l-heure

Déplacé sur http://www.julp.fr/blog/posts/6-optimisation-eviter-des-select-inutiles