Comment MySQL gère les contraintes

Comme MySQL permet de travailler avec des moteurs de tables transactionnels ou pas, les contraintes sont gérées un peu différemment sur MySQL que sur les autres bases de données. Nous devons gérer le cas où vous avez modifié beaucoup de lignes avec une table

non−transactionnelles, qui ne peut annuler les modifications en cas d'erreur.

La philosophie de base est d'essayer de détecter autant d'erreur que possible au moment de la compilation, mais d'essayer de réparer les erreurs à l'exécution. Nous y arrivons dans la plupart des cas, mais pas tout le temps. Ce qui est prévu pour un futur proche .

La solution de base de MySQL est d'interrompre la commande au milieu, ou de faire de son mieux pour réparer le problème et continuer.

Voici ce qui se passe dans les différents types de contraintes.

1.8.6.1 Contrainte avec PRIMARY KEY / UNIQUE

Normalement, vous allez obtenir une erreur lorsque vous essayerez d'insérer INSERT

ou modifier UPDATE

une ligne qui causera une violation de clé primaire, unique ou étrangère. Si vous utilisez un moteur transactionnelle, comme InnoDB, MySQL va immédiatement annuler la transaction. Si vous utilisez un moteur non−transactionnel, MySQL va s'arrêter à la mauvaise ligne, et laisser les dernières lignes intactes.

Pour rendre la vie plus facile, MySQL a ajouté le support de l'option IGNORE

aux commandes qui peuvent rencontrer un problème de clé (comme INSERT IGNORE ...

). Dans ce cas, MySQL va ignorer les problèmes de clé et la ligne, et continuer à traiter les lignes suivantes. Vous pouvez obtenir la liste des alertes avec la fonction mysql_info()

et, dans les prochaines versions de MySQL 4.1, vous pourrez aussi les voir avec la commande SHOW WARNINGS

. mysql_info()

. Syntaxe de SHOW WARNINGS

. Notez que pour le moment, seules les tables InnoDB

supportent les clés étrangères. Contraintes FOREIGN KEY

. Le support des clés étrangères des tables MyISAM

sont prévues pour la version 5.0.

1.8.6.2 Contraintes sur les valeurs invalides

Pour être capable de supporter facilement les tables non−transactionnelles, tous les champs de MySQL ont des valeurs par défaut.

Si vous insérez une valeur ``invalide'' dans une colonne, comme NULL

dans une colonne NOT NULL

, ou une valeur numérique trop grand dans une colonne numérique, MySQL inscrit dans la colonne la ``meilleure valeur possible'', sans produire d'erreur :

Si vous stockez un chiffre hors de l'intervalle de validité d'une colonne numérique, MySQL stocke à la place zéro, la plus petite valeur possible, ou bien la plus grande valeur possible.

•

Pour les chaînes, MySQL stocke la chaîne vide ou bien la plus grande chaîne qui peut être stockée dans cette colonne.

•

Si vous essayez de stocker une chaîne qui ne commence pas par un chiffre dans une colonne numérique, MySQL stocke 0.

•

Si vous essayez de stocker NULL

dans une colonne qui n'accepte pas la valeur NULL

, MySQL stocke 0 ou ''

(la chaîne vide). Ce dernier comportement peut, pour des insertions de ligne unique, être modifié par l'option de compilation −DDONT_USE_DEFAULT_FIELDS

. Les options habituelles de configure

. Cela fait que les commandes INSERT

génèreront une erreur à moins que vous ne spécifiez explicitement les valeurs pour toutes les colonnes qui requièrent une valeur non−

NULL

.

•

MySQL vous permet de stocker des dates incorrectes dans les colonnes de type DATE

et

DATETIME

(comme '2000−02−31'

ou '2000−02−00'

). L'idée est que ce n'est pas le travail du serveur SQL de valider les dates. Si MySQL peut stocker une valeur et relire exactement la même valeur, MySQL la stockera. Si la date est totalement erronée (hors de l'intervalle de validité), la valeur spéciale '0000−00−00'

est stockée dans la colonne.

•

La raison de cette règle ci−dessus est que nous ne pouvons pas vérifier ces conditions avant que la requête ne soit exécutée. Si nous rencontrons un problème après la modification de quelques lignes, nous ne pourront pas annuler la modification, car la table ne le supporte peut−être pas.

L'alternative qui consiste à s'arrêter c'est pas envisageable non plus, car nous aurions alors fait la moitié du travail, ce qui sera alors le pire scénario. Dans ce cas, il vaut mieux faire "du mieux possible", et continuer comme si rien n'était arrivé. En MySQL 5.0, nous envisageons d'améliorer cela en fournissant des alertes de conversions automatique, ainsi qu'une option pour vous permettre d'annuler la commande si elle n'utilise que des tables transactionnelles.

Ceci signifie qu'il ne faut pas compter sur MySQL pour vérifier le contenu des champs, mais de gérer cela au niveau de l'application.

1.8.6.3 Constante avec ENUM et SET

En MySQL 4.x ENUM

n'est pas une véritable contrainte, mais simplement un moyen plus efficace de stocker des champs qui peuvent prendre un nombre limité de valeurs différentes. C'est la même raison pour laquelle NOT NULL

n'est pas respecté.

Si vous insérez une valeur invalide dans un champs ENUM

, la colonne prendra la valeur réservée 0

, qui sera représentée par une chaîne vide, en mode chaîne. Le type ENUM

. Si vous insérez une mauvais option dans un ensemble SET

, la valeur sera ignorée. Le type SET

.