J'ai eu l'occasion de m'en entretenir avec Dvid Axmark à LSM 2000 et 2001. Cette année, ne n'en ai pas remis une couche ;).
Bien entendu, on doit vérifier que toutes les clés étrangères sont valides avant de faire un insert.
Quand le SGBD gère les clés étrangères, il refait le même travail. Une autre façon de procéder serait de tenter l'insert et de tester un à un tous les champs en cas d'erreur. Je trouve que ce n'est pas très propre, mais c'est une question de goût.
Le vrai problème de l'absence de la clé étrangère est l'intervention directe sur la base, sans passer par le programme normal. Il en résulte le plus souvent des situations calamiteuses. Juste un exemple : Dans une banque, on fait des opérations sur un compte (clé étrangère) Que se passe-t'il si il y a deux fois le même compte ou si le compte n'existe pas ?
A mon avis la gestion des foreign keys est la seule chose qui manque à MySQL pour jouer dans la même cour que Posgresql et Oracle.
[^] # Re: Foreign keys.
Posté par Pierre Jarillon (site web personnel) . En réponse à la dépêche Access .... dans OpenOffice ?. Évalué à 2.
Bien entendu, on doit vérifier que toutes les clés étrangères sont valides avant de faire un insert.
Quand le SGBD gère les clés étrangères, il refait le même travail. Une autre façon de procéder serait de tenter l'insert et de tester un à un tous les champs en cas d'erreur. Je trouve que ce n'est pas très propre, mais c'est une question de goût.
Le vrai problème de l'absence de la clé étrangère est l'intervention directe sur la base, sans passer par le programme normal. Il en résulte le plus souvent des situations calamiteuses. Juste un exemple : Dans une banque, on fait des opérations sur un compte (clé étrangère) Que se passe-t'il si il y a deux fois le même compte ou si le compte n'existe pas ?
A mon avis la gestion des foreign keys est la seule chose qui manque à MySQL pour jouer dans la même cour que Posgresql et Oracle.