Discussion :

[Marc31]

Bonjour,

Comment éviter que les personnes puissent rentrer une même personne dans une base de données.

Peut on le faire sur l'insert??

Merci et bonne journée.

[SQLpro]

Il suffit de mettre en place une contrainte d'unicité !

A +

[Marc31]

merci, c'est quoi une Contrainte d'unicité?

[SQLpro]

Ben si vous en êtes là... Revenez aux fichier CoBol !

A lire : http://sqlpro.developpez.com/cours/sqlaz/ddl/

Formez vous aux bases de données et au langage SQL en particulier... Mon livre peut vous y aider :


A +

[Artemus24]

Salut Marc31.

merci, c'est quoi une Contrainte d'unicité?

C'est un index unique.
--> https://dev.mysql.com/doc/refman/5.7...ate-index.html

Exemple :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

create unique index `idx` using btree on `votre_table` (`votre_colonne`);

@+

[SQLpro]

C'est un index unique.

Ben non !

une contrainte d'unicité n'est absolument pas un index unique. Vous confondez niveau logique et niveau physique ! Même si la plupart des SGBD créent un index unique pour un contrainte d'unicité, afin de satisfaire les performances de contrôle d'unicité de la clef.

A +

[Artemus24]

Salut SQLPRO.

J'attends votre démonstration de la contrainte d'unicité dans MySql si ce n'est pas un index unique.

@+

[Marc31]

Oui ça j'ai fais un index unique à chaque nouvelle intégration dans ma base de données, il y a une valeur unique autoincrementée.

[Christophe P.]

Bonjour,

une valeur unique autoincrementée ne permet pas forcément d'avoir une personne unique. Il faut peut-être ajouter une contrainte d'unicité sur le nom, le prénom et la date de naissance.

[Artemus24]

Salut Christophe P..

Le test de vérification doit se faire par application.
Avant d'insérer une nouvelle ligne dans la table, vérifier si cette personne est déjà présente. Un simple sélect fera l'affaire.
Rien n'empêche d'ajouter en plus, un index unique sur la ou les colonnes dont on désire avoir l'unicité.

Mais au préalable, il faut s'assurer que la collation utilisée soit capable de faire la distinction entre des noms avec et sans majuscule. Voire aussi avec ou sans accents.

Que type de charset utilisez-vous ? Et quel type de collation utilisez-vous ?
quel type de comparaison désirez-vous faire ?
Pour vous, "Dupont" (avec majuscule) et "dupont" (sans majuscule), est-ce pareil ou différent ?
Prenons aussi le cas de "marie laforet" (sans accent circonflexe) ou marie laforêt" (ou avec accent circonflexe), est-ce pareil ou différent ?

@+

[Felykanku]

la question si je ne me trompe pas consiste à gérer le doublon, bien sûr lors de l'insertion d'une nouvelle ligne dans la table concernée.
Mais cela peut être aussi resolu en faisant un selelect sur la colonne qui présente un contenu unique, cela avec une boucle while afin de comparer le contenu à insérer avec ceux déjà dans la BD.
Par contre, imposer un champ de la table en auto-increment n'est pas la vraie solution. Car il y aura redondance des infos quand bien même les numéros seront differents; ça reste toujours la même information...

Je demande à SQLPro s'il peut nous dire en quoi consiste la clé ou l'index ou encore les regles d'unicité???
Car nous avions apris toujours sur site au travers un tuto sur la programmation defensive que beaucoup avaient taxé d'une gestion d'exception que : "le contrôl avec select permet l'hors de l'insertion d'eviter les erreurs dues à la repetition des infos...."

L'avis détaillé de SQLPro nous interessera tous!!!

[Artemus24]

Salut Felykanku.

la question si je ne me trompe pas consiste à gérer le doublon ...

Pas exactement car un doublon, ce sont deux lignes dans votre table, ayant les mêmes critères.
Ici, la ligne n'est pas encore insérée dans votre table, donc on ne peut pas encore, à proprement parler de doublon.

Dans cette exemple, on peut faire trois tests pour vérifier l'existence du couple (nom ; prenom).

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
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
 
--------------
SET AUTOCOMMIT = 0
--------------
 
--------------
START TRANSACTION
--------------
 
--------------
DROP DATABASE IF EXISTS `base`
--------------
 
--------------
CREATE DATABASE `base`
    DEFAULT CHARACTER SET `latin1`
    DEFAULT COLLATE       `latin1_general_ci`
--------------
 
--------------
DROP TABLE IF EXISTS `test`
--------------
 
--------------
CREATE TABLE `test`
( `id`      integer unsigned not null auto_increment primary key,
  `nom`     varchar(255)     not null,
  `prenom`  varchar(255)     not null,
  unique index `idx` (`nom`,`prenom`)
) ENGINE=InnoDB
  DEFAULT CHARSET=`latin1` COLLATE=`latin1_general_ci`
  ROW_FORMAT=COMPRESSED
--------------
 
--------------
insert into `test` (`nom`,`prenom`) values
  ('Chevalier','Maurice'),('Einstein','Albert')
--------------
 
--------------
select * from `test` order by id
--------------
 
+----+-----------+---------+
| id | nom       | prenom  |
+----+-----------+---------+
|  1 | Chevalier | Maurice |
|  2 | Einstein  | Albert  |
+----+-----------+---------+
--------------
select  *
  from  test
 where  nom    like 'einstein'
   and  prenom like 'albert'
--------------
 
+----+----------+--------+
| id | nom      | prenom |
+----+----------+--------+
|  2 | Einstein | Albert |
+----+----------+--------+
--------------
insert into `test` (`nom`,`prenom`) values ('einstein','albert')
--------------
 
ERROR 1062 (23000) at line 57: Duplicata du champ 'einstein-albert' pour la clef 'idx'
--------------
drop trigger if exists `exitence`
--------------
 
--------------
CREATE TRIGGER `existence`
BEFORE INSERT ON `test`
FOR EACH ROW
BEGIN
  DECLARE doublon CONDITION FOR SQLSTATE '45000';
  DECLARE _msg    varchar(255);
  DECLARE _id     integer;
 
  select id from test where nom = new.nom and prenom = new.prenom into _id;
 
  if (_id is not null) then
     SET _msg = CONCAT('>>> Doublon id = ', cast(_id as char(20)), ', nom = ', new.nom, ', prenom = ', new.prenom, ' <<<');
     SIGNAL doublon  SET MESSAGE_TEXT = _msg, MYSQL_ERRNO = 1000;
  end if;
END
--------------
 
--------------
insert ignore into `test` (`nom`,`prenom`) values ('Newton',  'Isaac')
--------------
 
--------------
insert ignore into `test` (`nom`,`prenom`) values ('einstein','albert')
--------------
 
ERROR 1000 (45000) at line 84: >>> Doublon id = 2, nom = einstein, prenom = albert <<<
--------------
select * from `test` order by id
--------------
 
+----+-----------+---------+
| id | nom       | prenom  |
+----+-----------+---------+
|  1 | Chevalier | Maurice |
|  2 | Einstein  | Albert  |
|  4 | Newton    | Isaac   |
+----+-----------+---------+
--------------
COMMIT
--------------
 
--------------
SET AUTOCOMMIT = 1
--------------
 
Appuyez sur une touche pour continuer...

1) par un simple select.

2) en créant un "unique index" et en faisant un "insert".

3) par un déclencheur qui va tester si le couple (nom ; prenom) existe déjà ou pas. Dans ce cas, l'index unique ne sert à rien !

Ce ne sont pas les solutions qui manquent en mysql pour tester l'existence de valeurs dans une table.
Mais vu que la question posée est rudimentaire, il est difficile d'y répondre au mieux de ce qu'offre mysql comme possibilité.

L'avis détaillé de SQLPro nous intéressera tous!!!

A la condition que SQLPRO comprenne que nous sommes dans le modèle physique du SGBDR MySql et non dans un modèle logique de représentation des données.

@+

[SQLpro]

Le test de vérification doit se faire par application.
Avant d'insérer une nouvelle ligne dans la table, vérifier si cette personne est déjà présente. Un simple sélect fera l'affaire.
Rien n'empêche d'ajouter en plus, un index unique sur la ou les colonnes dont on désire avoir l'unicité.

Triplement stupide !
1) faire un teste par l'appli n'est possible qu'en faisant un SELECT préalable... ce qui impose une lecture de plus qu'un insert direct et ne sert a rien que bouffer du process et poser des verrous inutiles
2) tester par un select l'existence d'une personne n’empêchera pas un autre utilisateur de faire le même teste au même moment et d'en tirer la même conclusion. On se retrouve donc avec un doublon et la base est pourrie sans qu'aucun signal d'erreur soit envoyé ! Hautement stupide et parfaitement inutile !
3) rajouter un index unique (ou une contrainte d'unicité) est la seule solution viable et ne doit pas être envisagé "à la rigueur", mais n'est que la seule et unique solution viable.

Enfin en ce qui concerne la différence entre un index unique et une contrainte d'unicité, l'une est logique (contrainte) et ne soufre rien d'autre que l'unicité des valeurs exprimées et par conséquent autant de NULLs que l'on veut. L'autre est purement physique et doit être réservé au DBA et pas au développeur et permet d'ajouter des paramètres techniques que seule le DBA est capable d’apprécier en fonction de l'exploitation des données. Ce peut être un index unique filtré, un facteur de remplissage, etc...
Enfin en ce qui concerne les index unique (car MySQL ne connais visiblement pas les contraintes d'unicité - encore une imbécilité à la MySQmerde...) et fais croire que c'est l'équivalent alors qu'il n'en est rien... Il n'est qu'a lire la liste de bugs recensés sur cette problématique d'index unique de MySQmerde pour s'en convaincre :
https://bugs.mysql.com/bug.php?id=4140
https://bugs.mysql.com/bug.php?id=5685
https://bugs.mysql.com/bug.php?id=8173
https://bugs.mysql.com/bug.php?id=17825
https://bugs.mysql.com/bug.php?id=25544
https://bugs.mysql.com/bug.php?id=27019

Bref comme d'habitude dans MySQMerde on fait n'importe quoi et rien n'est jamais corrigé !

A +

[Felykanku]

à SQLPro !

[Artemus24]

Salut SQPLPRO.

Que de contradictions !

rajouter un index unique (ou une contrainte d'unicité) est la seule solution viable et ne doit pas être envisagé "à la rigueur", mais n'est que la seule et unique solution viable.

Alors en quoi est-ce stupide, quand j'ai formulé ma réponse au post #6 :

C'est un index unique.

Ben non !

A bien vous comprendre, quand l'idée vient de vous c'est génial mais quand cela vient de moi, c'est stupide !
Si cette attitude, n'est pas condescendante, je ne sais pas ce que c'est.

Et je vous rappelle que nous sommes dans le forum consacré au SGBDR MySql et non à la modélisation ou encore à Microsoft SQL Server, votre bébé.

Enfin en ce qui concerne la différence entre un index unique et une contrainte d'unicité, l'une est logique (contrainte) et ne soufre rien d'autre que l'unicité des valeurs exprimées et par conséquent autant de NULLs que l'on veut. L'autre est purement physique et doit être réservé au DBA et pas au développeur et permet d'ajouter des paramètres techniques que seule le DBA est capable d’apprécier en fonction de l'exploitation des données.

Donc l'index unique est à la charge du DBA et pas au développeur, admettons.
Et si le DBA ne veut pas créer un index unique, comment le développeur va-t-il faire pour résoudre son problème d'unicité ?
Par la clause "where not exists (select 1 from ... where ...)" dans un "insert", je le suppose.
Mais au fait, n'avez pas dit, quelques lignes plus haut, que tester l'existence par un select est stupide ?

Et tout ça, pour démontrer votre total ignorance des transactions !

Vous n'avez rien trouvé de plus récent que des bugs datant de 2004 à 2007, soit il y a plus de dix ans ???
C'est avec ce genre d'argument que vous essayez de convaincre que MySql, c'est de la merde. Selon moi, c'est de la mauvaise foi et rien d'autre !

Avez-vous ces dix dernières années, fait au moins une fois du MySql ? Non !
Et après ça, vous voulez nous donner des leçons ! Commencez par mettre les mains dans le cambouis et on en reparlera !

Je n'ai pas comme vous la prétention de tout connaitre, mais je pratique MySql, FireBird, un peu de Microsoft SQL server et jadis du DB2. Et vous ?
Sans parler non plus, quand je faisais du gros système BULL IDS II, ou sur IBM IDMS, DL1, IMS, focus.

Et à l'inverse de vous, j'essaye d'aider les membres de ce forums au lieu de toujours les rabaisser, comme vous le faite.

Mettez moi encore des '-1', puisque vous n'aimez pas la contradiction !

@+

[Marc31]

J'ai essayé de faire une requete sql select.... mais je ne vois pas comment l'intégrer avant mon insert.

J'ai fais un select ... nom like "'.$nom.'" and prenom like "'.$prenom.'" pour que s'il me trouve cela dans la base de données, il arrête l'insert.

Après j'ai ma requete insert mais comment je peux lui dire stop s'il trouve le même nom et prenom??

Merci.

[Artemus24]

Salut Marc31.

Tout dépend de ce que vous désirez faire :

1) soit en cas de doublon, vous désirez mettre à jour votre table avec les nouvelles informations.
Vous devez créez un "unique index" sur les colonnes "nom" et "prenom", puisque votre doublon concerne ces deux colonnes. Voici un exemple :

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
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
--------------
SET AUTOCOMMIT = 0
--------------
 
--------------
START TRANSACTION
--------------
 
--------------
DROP DATABASE IF EXISTS `base`
--------------
 
--------------
CREATE DATABASE `base`
    DEFAULT CHARACTER SET `latin1`
    DEFAULT COLLATE       `latin1_general_ci`
--------------
 
--------------
DROP TABLE IF EXISTS `test`
--------------
 
--------------
CREATE TABLE `test`
( `id`       integer unsigned not null auto_increment primary key,
  `nom`      varchar(255)     not null,
  `prenom`   varchar(255)     not null,
  `libelle`  varchar(255)     not null,
  unique index `idx` (`nom`,`prenom`)
) ENGINE=InnoDB
  DEFAULT CHARSET=`latin1` COLLATE=`latin1_general_ci`
  ROW_FORMAT=COMPRESSED
--------------
 
--------------
insert into `test` (`nom`,`prenom`,`libelle`) values
  ('Chevalier','Maurice','compositeur'),
  ('Einstein', 'Albert', 'savant'),
  ('Legrand',  'Albert', 'particulier')
--------------
 
--------------
select * from `test` order by id
--------------
 
+----+-----------+---------+-------------+
| id | nom       | prenom  | libelle     |
+----+-----------+---------+-------------+
|  1 | Chevalier | Maurice | compositeur |
|  2 | Einstein  | Albert  | savant      |
|  3 | Legrand   | Albert  | particulier |
+----+-----------+---------+-------------+
--------------
insert into `test` (`nom`,`prenom`,`libelle`) values
  ('einstein','albert','physicien théoricien'),
  ('newton',  'issac', 'philosophe, mathématicien, physicien, alchimiste, astronome et théologien')
  on duplicate key update libelle = values(`libelle`)
--------------
 
--------------
select * from `test` order by id
--------------
 
+----+-----------+---------+---------------------------------------------------------------------------+
| id | nom       | prenom  | libelle                                                                   |
+----+-----------+---------+---------------------------------------------------------------------------+
|  1 | Chevalier | Maurice | compositeur                                                               |
|  2 | Einstein  | Albert  | physicien théoricien                                                      |
|  3 | Legrand   | Albert  | particulier                                                               |
|  4 | newton    | issac   | philosophe, mathématicien, physicien, alchimiste, astronome et théologien |
+----+-----------+---------+---------------------------------------------------------------------------+
--------------
COMMIT
--------------
 
--------------
SET AUTOCOMMIT = 1
--------------
 
Appuyez sur une touche pour continuer...

On constate que dans le cas "einstein+albert", la colonne 'libelle' a été mise à jour.
Tandis que dans le cas "newton+issac", il y a bien eu une insertion.
Donc on aura jamais de doulons (nom+prenom) dans la table.

2) rejet de la ligne en cas de doublon.
Dans ce cas là, c'est bien plus simple que précédemment, car il suffit de faire un insert classique.
L'index unique est toujours présente car c'est ce qui détermine le doublon sur le couple (nom ; prenom).
Je ne remets pas la création de la table.

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
--------------
select * from `test` order by id
--------------
 
+----+-----------+---------+-------------+
| id | nom       | prenom  | libelle     |
+----+-----------+---------+-------------+
|  1 | Chevalier | Maurice | compositeur |
|  2 | Einstein  | Albert  | savant      |
|  3 | Legrand   | Albert  | particulier |
+----+-----------+---------+-------------+
--------------
insert into `test` (`nom`,`prenom`,`libelle`) values ('einstein','albert','physicien théoricien')
--------------
 
ERROR 1062 (23000) at line 66: Duplicata du champ 'einstein-albert' pour la clef 'idx'
--------------
insert into `test` (`nom`,`prenom`,`libelle`) values ('newton',  'issac', 'philosophe, mathématicien, physicien, alchimiste, astronome et théologien')
--------------
 
--------------
select * from `test` order by id
--------------
 
+----+-----------+---------+---------------------------------------------------------------------------+
| id | nom       | prenom  | libelle                                                                   |
+----+-----------+---------+---------------------------------------------------------------------------+
|  1 | Chevalier | Maurice | compositeur                                                               |
|  2 | Einstein  | Albert  | savant                                                                    |
|  3 | Legrand   | Albert  | particulier                                                               |
|  5 | newton    | issac   | philosophe, mathématicien, physicien, alchimiste, astronome et théologien |
+----+-----------+---------+---------------------------------------------------------------------------+

Le cas "einstein+albert" est rejeté car une ligne existe déjà. Il faut tester le code retour lors de chaque insert.
Et en cas d'erreur, c'est à vous de gérer ce rejet.

3) La table n'a pas changé, mais cette fois-ci, il n'y a pas de "unique index".
Donc vous devez gérer par vous même le doublon (nom ; prenom).

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
35
36
37
38
39
40
41
--------------
select * from `test` order by id
--------------
 
+----+-----------+---------+-------------+
| id | nom       | prenom  | libelle     |
+----+-----------+---------+-------------+
|  1 | Chevalier | Maurice | compositeur |
|  2 | Einstein  | Albert  | savant      |
|  3 | Legrand   | Albert  | particulier |
+----+-----------+---------+-------------+
--------------
insert into `test` (`nom`,`prenom`,`libelle`)
          select  'einstein'             as nom,
                  'albert'               as prenom,
                  'physicien théoricien' as libelle
            from  dual
where not exists  (select 1 from test as t1 where t1.nom = 'einstein' and t1.prenom = 'albert')
--------------
 
--------------
insert into `test` (`nom`,`prenom`,`libelle`)
          select  'newton'                                                                    as nom,
                  'issac'                                                                     as prenom,
                  'philosophe, mathématicien, physicien, alchimiste, astronome et théologien' as libelle
            from  dual
where not exists  (select 1 from test as t1 where t1.nom = 'newton' and t1.prenom = 'isaac')
--------------
 
--------------
select * from `test` order by id
--------------
 
+----+-----------+---------+---------------------------------------------------------------------------+
| id | nom       | prenom  | libelle                                                                   |
+----+-----------+---------+---------------------------------------------------------------------------+
|  1 | Chevalier | Maurice | compositeur                                                               |
|  2 | Einstein  | Albert  | savant                                                                    |
|  3 | Legrand   | Albert  | particulier                                                               |
|  4 | newton    | issac   | philosophe, mathématicien, physicien, alchimiste, astronome et théologien |
+----+-----------+---------+---------------------------------------------------------------------------+

Dual sous MySql est une table fictive.

La ligne "einstein+albert" n'a pas été modifié, tandis que la ligne "newton+isaac" a bien été insérée.

Si vous désirez éviter de mettre deux fois la valeur du nom et du prénom dans votre requête, vous pouvez écrire ainsi :

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
35
36
37
38
39
40
41
42
43
44
45
--------------
select * from `test` order by id
--------------
 
+----+-----------+---------+-------------+
| id | nom       | prenom  | libelle     |
+----+-----------+---------+-------------+
|  1 | Chevalier | Maurice | compositeur |
|  2 | Einstein  | Albert  | savant      |
|  3 | Legrand   | Albert  | particulier |
+----+-----------+---------+-------------+
--------------
insert into `test` (`nom`,`prenom`,`libelle`)
          select  *
            from  (  select  'einstein'             as nom,
                             'albert'               as prenom,
                             'physicien théoricien' as libelle
                       from  dual
                  ) as t1
where not exists  (select 1 from test as t2 where t2.nom = t1.nom and t2.prenom = t1.prenom)
--------------
 
--------------
insert into `test` (`nom`,`prenom`,`libelle`)
          select  *
            from  (  select  'newton'                                                                    as nom,
                             'issac'                                                                     as prenom,
                             'philosophe, mathématicien, physicien, alchimiste, astronome et théologien' as libelle
                       from  dual
                  ) as t1
where not exists  (select 1 from test as t2 where t2.nom = t1.nom and t2.prenom = t1.prenom)
--------------
 
--------------
select * from `test` order by id
--------------
 
+----+-----------+---------+---------------------------------------------------------------------------+
| id | nom       | prenom  | libelle                                                                   |
+----+-----------+---------+---------------------------------------------------------------------------+
|  1 | Chevalier | Maurice | compositeur                                                               |
|  2 | Einstein  | Albert  | savant                                                                    |
|  3 | Legrand   | Albert  | particulier                                                               |
|  4 | newton    | issac   | philosophe, mathématicien, physicien, alchimiste, astronome et théologien |
+----+-----------+---------+---------------------------------------------------------------------------+

Même résultat que précédemment.

En espérant que cela réponde à votre attente !

@+

[SQLpro]

Donc l'index unique est à la charge du DBA et pas au développeur, admettons.
Et si le DBA ne veut pas créer un index unique, comment le développeur va-t-il faire pour résoudre son problème d'unicité ?

Tout simplement changer de SGBD pour un vrai SGBD réellement relationnel ce que MySQL n'est pas... ! Ce n'est pas parce que un produit met dans son nom l'acronyme SQL (qui d'ailleurs est un langage) qu'il est relationnel... et déjà en 1985 Franck Edgar Codd l’inventeur des bases de données relationnelle attirait l'attention des utilisateurs sur ce problème car pleins de produit prétendait être relationnel mais ne l'était pas dut tout dans les faits. C'est pourquoi il édictât les 12 règles de Codd que tous les SGBD Relationnel devait respecter à la lettre. Je vous invite à les relire et vérifier par vous même : http://sqlpro.developpez.com/SGBDR/ReglesCodd/

...

Vous n'avez rien trouvé de plus récent que des bugs datant de 2004 à 2007, soit il y a plus de dix ans ???

C'est justement catastrophiquement navrant de voir que des bugs recensés en 2007 ne sont toujours pas corrigés en 2017 !!!!!
Donc, je maintient que MySQL est une vraie daube et je voit de plus en plus de clients qui ont sombré dans ce produit infâme qui sont bloqués et n'arrivent plus à en sortir... C'est pourquoi j'attire l'attention sur le fait qu’il vaut mieux l'éviter et prendre par exemple un vrai SGBDR libre comme PostgreSQL - ce que MySQL n'est pas ! (il faut le payer d'une manière ou d'une autre, ce qui n'est pas le cas d'ailleurs avec MariaDB)

C'est avec ce genre d'argument que vous essayez de convaincre que MySql, c'est de la merde. Selon moi, c'est de la mauvaise foi et rien d'autre !

Avez-vous ces dix dernières années, fait au moins une fois du MySql ? Non !

Le moins possible et hélas parfois pour faire passer des applis de MySQL à PG ou SQL Server

Et après ça, vous voulez nous donner des leçons ! Commencez par mettre les mains dans le cambouis et on en reparlera !


Je n'ai pas comme vous la prétention de tout connaitre, mais je pratique MySql, FireBird, un peu de Microsoft SQL server et jadis du DB2. Et vous ?

Voulez-vous que je vous communique mon CV ? Personnellement voici les SGBDR avec lequel j'ai travaillé avant de me spécialiser sur SQL Server :
Ingres, RDB, Informix, Gupta SQL, Oracle, Sybase (ASE, ASA), Watcom SQL, Ocelot (de Peter Gulutzan que je connais bien puisqu'il à traduit un de mes articles en anglais et qu'il est le responsable du développement du noyau SQL de MySQmerde et intervanant pour Oracle/MySQL au comité de pilotage de la norme SQL ANSI...), Paradox, DBase, 4 D, IBM DB2, PostGreSQL et j'en ais certainement oublié quelques uns.
Et comme atelier de modélisation AMC Designor, Tramis, ER Win et Win Design...

...

Et à l'inverse de vous, j'essaye d'aider les membres de ce forums au lieu de toujours les rabaisser, comme vous le faite.

Je ne rabaisse personne, mais je rectifie des propos imbéciles que cela vous plaise ou non, car je ne suis pas du tout adepte du consensus mou ni du politiquement correct et je préfère donc signaler les dangers de l'utilisation d'un produit particulièrement imbécile !

Mettez moi encore des '-1', puisque vous n'aimez pas la contradiction !

J'en mettrais aussi souvent que j'estimerais si vos propos sont idiots stupide ou malvenus ! Je dois reconnaître que vous aidez pas mal les utilisateurs a se dépatouiller du merdier MySQL !

A +

[escartefigue]

1) faire un teste par l'appli n'est possible qu'en faisant un SELECT préalable... ce qui impose une lecture de plus qu'un insert direct et ne sert a rien que bouffer du process et poser des verrous inutiles
2) tester par un select l'existence d'une personne n’empêchera pas un autre utilisateur de faire le même teste au même moment et d'en tirer la même conclusion. On se retrouve donc avec un doublon et la base est pourrie sans qu'aucun signal d'erreur soit envoyé ! Hautement stupide et parfaitement inutile !
3) rajouter un index unique (ou une contrainte d'unicité) est la seule solution viable et ne doit pas être envisagé "à la rigueur", mais n'est que la seule et unique solution viable.

Je plussoie avec énergie et m'inquiète de constater que 2 personnes ont voté contre ce post