(Des valeurs peuvent excéder le range, sans garantie sur le résultat)

Chaque type peut avoir 0 comme valeur pour représenter une valeur insérée illégale. Le format par défaut est YYYY-MM-DD. Cependant, le format YYYY-M-D (2009-1-1) est supporté. De plus, le séparateur – n’est pas obligatoire, on peut également utiliser / (2009/01/01)

L’affichage des années peut se faire avec 2 ou 4 chiffres. Lorsque représenté avec 2 chiffres, 70 à 99 représente 1970 à 1999 alors que 00 à 69 représente 2000 à 2069.

Pour que les timestamps s’updatent automatiquement à l’insertion ou l’update, il faut spécifier l’option DEFAULT CURRENT_TIMESTAMP ou ON UPDATE CURRENT_TIMESTAMP. Cependant, pour conserver une compatibilité avec MySQL 4.1, ils sont considérés par défaut sur la première colonne timestamp.

Les 2 attributs peuvent être setté sur le même champ, mais il est impossible de mettre 1 différent attribut sur 2 champs. Par contre, la compatibilité avec MySQL 4.1 permet de tricher en ne spécifiant pas le DEFAULT CURRENT_TIMESTAMP sur la première colonne, et le ON UPDATE.. sur une 2ieme.

Si on ne veut pas qu’une colonne timestamp s’update automatiquement, il faut explicitement mettre sa par défaut à NULL.

Pour modifier le timezone, il faut changer la variable système : SET global time_zone = ‘+05 :00′; Par défaut, c’est le timezone du système. Si un client modifie le timezone, la même valeur sera différente d’un client à l’autre. Ce changement modifie aussi la valeur retournée par NOW().

SELECT CONVERT_TZ(’2005-01-27 13:30 :00′,’+01:00′,’+03:00);

2005-01-27 15:30 :00

Integer

Quand on spécifie une “longueur” de champs:
Les nombres plus petits que la longueur sont paddés d’espace jusqu’à la longueur. Les longueurs par défaut de MySQL incluent le signe négatif, donc un smallint est 6 (et non 5)

Floatint-Point

Inclus les types FLOAT et DOUBLE. Ils peuvent être utilisés pour représenter des valeurs approximatives et utilisent le native binary floating-point format du CPU. Ils sont très performants, mais sujet aux erreurs d’arrondissement.

Il est possible de définir la « precision and scale ».
FLOAT(10,3) indique un maximum de 10 chiffres, dont 3 après la virgule.
DECIMAL(20,7) indique un maximum de 20 chiffres, dont 7 après la virgule.

FLOAT utilise 4 bytes maximum, ce qui donne une précision entre 0 et 23. DOUBLE utilise 8 bytes, offrant une précision de 24 à 53.

Fixed-Point

Le type DECIMAL (ou NUMERIC) peut stocker des valeurs exactes. Il n’utilise pas le format binaire natif donc il est plus CPU Intensive. La précision et le scale influencent le nombre de bytes utilisé pour le stockage. Environ 4 bytes sont requis par tranche de 9 chiffres de chaque côté de la décimale.

Bit

La grosseur du champ BIT indique le nombre de bits par valeur, allant de 1 à 64. Le range de valeur se calcule 0 à 2n -1 et le nombre de bytes pour le stockage se calcule INT((n+7) / 8 ). On peut assigner des valeurs numériques ou des valeurs binaires avec la notation b’val’. Par exemple, b’1111′ représente 15 alors que b’1000000′ représente 64.

• Le filesystem va mieux cacher les fichiers
• Le serveur MySQL va avoir plus de facilité à cacher les autres données
• Le débit de donnée du serveur va être moins élevé
• Il est plus facile de réorganiser et maintenir les fichiers
• Le tablespace demeure petit (si vous devez utiliser InnoDB)

Une bonne approche est de stocker un pointeur vers les fichiers sur le filesystem plutôt que le binaire du fichier directement dans la BD. Il y a cependant des avantages à les stocker dans la base de données:

• Toutes les données sont centralisées à une place pour les backups
• C’est plus simple à gérer avec la réplication et/ou du load balancing
• Il est possible de demeurer ACID compliant.

J’ai eu une situation qui aurait pu devenir très problématique dernièrement lorsque je devais faire la maintenance de la base de données de l’application RT. Pour faire une histoire courte, RT stock des attachements d’email dans une table InnoDB et le tablespace d’InnoDB est devenu corrompu lorsqu’il a atteint 40 Go. Lorsqu’on sélectionnait des enregistrements précis de la table Attachements, le serveur plantait et mysql_safe le repartait automatiquement. Heureusement, il s’agissait d’un Slave. Comme nous avions qu’un seul slave, nous avons du le “reconstruire” à partir du Master. 40Go de données, c’est long à backuper et restaurer et le downtime que ça a créé était considérablement long. Un downtime est toujours trop long. Sur les 40Go, environ 30 étaient des fichiers d’attachements. Ça aurait été beaucoup plus simple et rapide si les fichiers n’étaient pas stockés dans MySQL…