Discussion :

[moimp]

Bonjour,
J'ai la fonction PHP suivante:

Code :

S�lectionner tout - Visualiser dans une fen�tre � part

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 :

S�lectionner tout - Visualiser dans une fen�tre � part

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?

[gabi7756]

Bonjour,

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

[moimp]

J'ai trouv�. J'avais une faute dans mon index unique.

[escartefigue]

Bonjour,

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).

[moimp]

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

Code SQL :

S�lectionner tout - Visualiser dans une fen�tre � part

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;

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.

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.

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.

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.

[escartefigue]

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.

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.

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.

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.