Le mot clef IGNORE reste sans effet

Version imprimable

Bonjour,
J'ai la fonction PHP suivante:

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
function insertPerson(array $data): string|false {
	$db = dbConnect();
 
	$sql = <<<SQL
	INSERT IGNORE INTO dat_persons
	(id_abo, gender, lastname, firstname, middlename, birthyear, birthmonth, birthday, birthplace,
		christeningyear, christeningmonth, christeningday, deathyear, deathmonth, deathday, deathplace,
		profession, comment, id_father, id_mother, birthorder)
	VALUES(:id_abo, :gender, :lastname, :firstname, :middlename, :birthyear, :birthmonth, :birthday, :birthplace,
		:christeningyear, :christeningmonth, :christeningday, :deathyear, :deathmonth, :deathday, :deathplace,
		:profession, :comment, :id_father, :id_mother, :birthorder)
	SQL;
	$stmt = $db->prepare($sql);
	$stmt->execute($data);
	return $db->lastInsertId();
}

et la structure de table de base de données suivante:

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
CREATE TABLE IF NOT EXISTS `dat_persons` (
  `id` int(10) UNSIGNED NOT NULL AUTO_INCREMENT,
  `id_abo` int(10) UNSIGNED NOT NULL,
  `gender` char(1) NOT NULL,
  `lastname` varchar(30) NOT NULL,
  `firstname` varchar(30) NOT NULL,
  `middlename` varchar(45) DEFAULT NULL COMMENT 'autres prénoms',
  `birthyear` char(4) DEFAULT NULL,
  `birthmonth` char(2) DEFAULT NULL,
  `birthday` char(2) DEFAULT NULL,
  `birth_date` date DEFAULT NULL,
  `birthplace` varchar(40) DEFAULT NULL,
  `christeningyear` char(4) DEFAULT NULL,
  `christeningmonth` char(2) DEFAULT NULL,
  `christeningday` char(2) DEFAULT NULL,
  `christening_date` date DEFAULT NULL COMMENT 'date de baptême',
  `deathyear` char(4) DEFAULT NULL,
  `deathmonth` char(2) DEFAULT NULL,
  `deathday` char(2) DEFAULT NULL,
  `death_date` date DEFAULT NULL,
  `deathplace` varchar(40) DEFAULT NULL,
  `profession` varchar(60) DEFAULT NULL,
  `comment` tinytext COMMENT 'annotations',
  `id_father` int(10) UNSIGNED DEFAULT NULL COMMENT 'clefPere',
  `id_mother` int(10) UNSIGNED DEFAULT NULL COMMENT 'clefMere',
  `birthorder` tinyint(2) DEFAULT NULL COMMENT 'ordre_dans_fratrie',
  `selected` tinyint(1) DEFAULT NULL,
  `create_date` datetime DEFAULT CURRENT_TIMESTAMP,
  `update_date` datetime DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP,
  PRIMARY KEY (`id`),
  UNIQUE KEY `person` (`id_abo`,`lastname`,`firstname`,`birth_date`,`id_mother`),
  KEY `father_id` (`id_father`),
  KEY `mother_id` (`id_mother`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;

Lorsque j'insère plusieurs fois un jeu de données, l'enregistrement est dupliqué où seule la date de mise à jour varie. Comment empêcher cet enregistrement?

26/12/2024, 17h10
gabi7756

Bonjour,

Citation:

Lorsque j'insère plusieurs fois un jeu de données, l'enregistrement est dupliqué où seule la date de mise à jour varie. Comment empêcher cet enregistrement?

Si la Pk est déjà présente ca va te lâcher un bon message d'erreur :)

N'étant pas confronté à cette problématique je te laisse chercher ton bonheur s'il s'y trouve dans ce fil de discussion :
https://stackoverflow.com/questions/...ate-key-update

Cdt
26/12/2024, 20h24
moimp

J'ai trouvé. J'avais une faute dans mon index unique.
27/12/2024, 11h46
escartefigue
Bonjour,

Citation:

Envoyé par moimp

et la structure de table de base de données suivante

Plusieurs choses me surprennent dans la définition de cette table :
- la date de naissance comma la date de décès sont stockées dans plusieurs colonnes de type char. C'est à la fois plus encombrant qu'un type date, mais aussi et surtout c'est une source d'erreurs et on compromet l'utilisation des fonctions date ;
- il n'y a aucune contrainte de clef étrangère, l'intégrité référentielle n'est donc pas vérifiée ;
- la colonne middlename a pour commentaire "autres prénoms", or, une liste de valeur est un viol de 1NF et c'est la source de bien des difficultés ;
- la plupart des colonnes sont "nullables", là aussi c'est la source de bien des difficultés (logique trivaluée).

J'ai apporté quelques modifications à la structure de la table (index unique). Voici la nouvelle structure:
Code:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 CREATE TABLE IF NOT EXISTS `dat_persons` ( `id` int(10) UNSIGNED NOT NULL AUTO_INCREMENT, `id_abo` int(10) UNSIGNED NOT NULL, `gender` char(1) NOT NULL, `lastname` varchar(30) NOT NULL, `firstname` varchar(30) NOT NULL, `middlename` varchar(45) DEFAULT NULL COMMENT 'autres prénoms', `birthyear` char(4) DEFAULT NULL, `birthmonth` char(2) DEFAULT NULL, `birthday` char(2) DEFAULT NULL, `birth_date` date DEFAULT NULL, `birthplace` varchar(40) DEFAULT NULL, `christeningyear` char(4) DEFAULT NULL, `christeningmonth` char(2) DEFAULT NULL, `christeningday` char(2) DEFAULT NULL, `christening_date` date DEFAULT NULL COMMENT 'date de baptême', `deathyear` char(4) DEFAULT NULL, `deathmonth` char(2) DEFAULT NULL, `deathday` char(2) DEFAULT NULL, `death_date` date DEFAULT NULL, `deathplace` varchar(40) DEFAULT NULL, `profession` varchar(60) DEFAULT NULL, `comment` tinytext COMMENT 'annotations', `id_father` int(10) UNSIGNED DEFAULT NULL COMMENT 'clefPere', `id_mother` int(10) UNSIGNED DEFAULT NULL COMMENT 'clefMere', `birthorder` tinyint(2) DEFAULT NULL COMMENT 'ordre_dans_fratrie', `selected` tinyint(1) DEFAULT NULL, `create_date` datetime DEFAULT CURRENT_TIMESTAMP, `update_date` datetime DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP, PRIMARY KEY (`id`), UNIQUE KEY `person` (`id_abo`,`lastname`,`firstname`,`birthyear`,`birthmonth`,`birthday`,`id_mother`) USING BTREE, KEY `father_id` (`id_father`), KEY `mother_id` (`id_mother`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4; ALTER TABLE `dat_persons` ADD CONSTRAINT `dat_persons_ibfk_1` FOREIGN KEY (`id_abo`) REFERENCES `dat_subscribers` (`id`) ON DELETE CASCADE ON UPDATE CASCADE;
Citation:

Envoyé par escartefigue

la date de naissance comma la date de décès sont stockées dans plusieurs colonnes de type char. C'est à la fois plus encombrant qu'un type date, mais aussi et surtout c'est une source d'erreurs et on compromet l'utilisation des fonctions date

Comme je l'avais indiqué dans une précédente question, il s'agit d'une application de généalogie où les dates ne sont pas toujours connues. Parfois on ne connait que l'année, parfois l'anniversaire mais pas l'année. Parfois rien du tout.

Citation:

Envoyé par escartefigue

il n'y a aucune contrainte de clef étrangère, l'intégrité référentielle n'est donc pas vérifiée;

Je ne l'avais pas mise la première fois, elle est dans la nouvelle définition.

Citation:

Envoyé par escartefigue

la colonne middlename a pour commentaire "autres prénoms", or, une liste de valeur est un viol de 1NF et c'est la source de bien des difficultés;

Cette donnée est une chaîne qui forme un tout avec les prénoms tels qu'ils figurent à l'état-civil.

Citation:

Envoyé par escartefigue

la plupart des colonnes sont "nullables", là aussi c'est la source de bien des difficultés (logique trivaluée).

Là, j'aurais besoin de plus d'explications. Si une colonne contient une chaîne vide au lieu d'une valeur nulle j'ai une détection de doublons où il n'y en a pas. Encore un problème de généalogie et de données incomplètes.

Mon problème reste entier, malgré la modification de l'index unique, je peux enregistrer des doublons. La difficulté est dans la définition de cet index unique, compte tenu des colonnes plus ou moins complètes. Trop de contraintes empêche l'enregistrement de données incomplètes, pas assez permet les doublons.

27/12/2024, 14h30
escartefigue

Citation:

Envoyé par moimp

Comme je l'avais indiqué dans une précédente question, il s'agit d'une application de généalogie où les dates ne sont pas toujours connues. Parfois on ne connait que l'année, parfois l'anniversaire mais pas l'année. Parfois rien du tout.

Ah oui, ça me revient en effet, pardon pour cet oubli.

Citation:

Envoyé par moimp

Je ne l'avais pas mise la première fois, elle est dans la nouvelle définition.

OK pour id_abo, mais les autres identifiants tels que id_father et id_mother devraient eux aussi faire l'objet de contraintes d'intégrité.
De plus, je trouve dommage qu'un identifiant de même nature change de nom en fonction de la table dans laquelle il se trouve. C'est probablement du à une définition des tables avec Workbench.
Quand on utilise un logiciel de modélisation (Power-AMC, DB-Main, Looping...), par défaut, un même identifiant porte le même nom dans toutes les tables. C'est beaucoup plus facile pour s'y retrouver.

Citation:

Envoyé par moimp

Cette donnée est une chaîne qui forme un tout avec les prénoms tels qu'ils figurent à l'état-civil.

Si la donnée est reçue sous cette forme, alors je comprends qu'elle soit stockée ainsi sans transformation.

Citation:

Envoyé par moimp

Là, j'aurais besoin de plus d'explications. Si une colonne contient une chaîne vide au lieu d'une valeur nulle j'ai une détection de doublons où il n'y en a pas. Encore un problème de généalogie et de données incomplètes.

Ce qui doit être unique, c'est la personne avec ses liens de parenté. Les données facultatives peuvent être stockées séparément dans une table liée à la personne.