Comme vous voyez, nous n'avons toujours qu'une seule tortue du nom de Spoutnik, mais il ne s'agit plus du mâle né le 2 avril
2007 que nous avions précédemment, mais bien de la femelle née le 6 août 2010 que nous venons d'insérer avec REPLACE
INTO. L'autre Spoutnik a été purement et simplement remplacé.
Attention cependant, quand je dis que l'ancien Spoutnik a été remplacé, j'utilise le terme "remplacé", car il s'agit de la traduction
de REPLACE. Il s'agit cependant d'un abus de langage. En réalité, la ligne de l'ancien Spoutnik a été supprimée, et ensuite
seulement, le nouveau Spoutnik a été inséré. C'est d'ailleurs pour cela que les deux Spoutnik n'ont pas du tout le même id.
Remplacement de plusieurs lignes
Pourquoi ai-je bien précisé qu'il ne s'agissait pas vraiment d'un remplacement, mais d'une suppression suivie d'une insertion ?
Parce que ce comportement a des conséquences qu'il ne faut pas négliger !
Prenons par exemple une table sur laquelle existent plusieurs contraintes d'unicité. C'est le cas d'Animal, puisqu'on a cet index
UNIQUE (nom, espece_id ), ainsi que la clé primaire (l'id doit donc être unique aussi).
Nous allons insérer avec REPLACE une ligne qui viole les deux contraintes d'unicité :
Code : SQL
REPLACE INTO Animal (id, sexe, nom, date_naissance, espece_id) -- Je
donne moi-même un id, qui existe déjà !
VALUES (32, 'M', 'Spoutnik', '2009-07-26 11:52:00', 3);
-- Et
Spoutnik est mon souffre-douleur du jour.
Code : Console
Query OK, 3 rows affected (0.05 sec)
Cette fois-ci, trois lignes ont été affectées. Trois !
Tout simplement, les deux lignes qui empêchaient l'insertion à cause des contraintes d'unicité ont été supprimées. La ligne qui
avait l'id 32, ainsi que l'ancien Spoutnik ont été supprimés. Le nouveau Spoutnik a ensuite été inséré.
Je l'ai fait ici pour vous donner un exemple, mais je rappelle que c'est une très mauvaise idée de donner soi-même un id
lorsque la colonne est auto-incrémentée (ce qui sera presque toujours le cas).
LOAD DATA INFILE
REPLACE est également disponible avec LOAD DATA INFILE. Le comportement est exactement le même.
Bien entendu, IGNORE et REPLACE ne peuvent pas être utilisés en même temps. C'est l'un ou l'autre.
Syntaxe
Code : SQL
LOAD DATA [LOCAL] INFILE 'nom_fichier' REPLACE
-- se place au
même endroit que IGNORE
INTO TABLE nom_table
[FIELDS
[TERMINATED BY '\t']
[ENCLOSED BY '']
[ESCAPED BY '\\' ]
]
[LINES
[STARTING BY '']
[TERMINATED BY '\n']
]
[IGNORE nombre LINES]
[(nom_colonne,...)];
Partie 2 : Index, jointures et sous-requêtes
145/414
www.openclassrooms.com
2007 que nous avions précédemment, mais bien de la femelle née le 6 août 2010 que nous venons d'insérer avec REPLACE
INTO. L'autre Spoutnik a été purement et simplement remplacé.
Attention cependant, quand je dis que l'ancien Spoutnik a été remplacé, j'utilise le terme "remplacé", car il s'agit de la traduction
de REPLACE. Il s'agit cependant d'un abus de langage. En réalité, la ligne de l'ancien Spoutnik a été supprimée, et ensuite
seulement, le nouveau Spoutnik a été inséré. C'est d'ailleurs pour cela que les deux Spoutnik n'ont pas du tout le même id.
Remplacement de plusieurs lignes
Pourquoi ai-je bien précisé qu'il ne s'agissait pas vraiment d'un remplacement, mais d'une suppression suivie d'une insertion ?
Parce que ce comportement a des conséquences qu'il ne faut pas négliger !
Prenons par exemple une table sur laquelle existent plusieurs contraintes d'unicité. C'est le cas d'Animal, puisqu'on a cet index
UNIQUE (nom, espece_id ), ainsi que la clé primaire (l'id doit donc être unique aussi).
Nous allons insérer avec REPLACE une ligne qui viole les deux contraintes d'unicité :
Code : SQL
REPLACE INTO Animal (id, sexe, nom, date_naissance, espece_id) -- Je
donne moi-même un id, qui existe déjà !
VALUES (32, 'M', 'Spoutnik', '2009-07-26 11:52:00', 3);
-- Et
Spoutnik est mon souffre-douleur du jour.
Code : Console
Query OK, 3 rows affected (0.05 sec)
Cette fois-ci, trois lignes ont été affectées. Trois !
Tout simplement, les deux lignes qui empêchaient l'insertion à cause des contraintes d'unicité ont été supprimées. La ligne qui
avait l'id 32, ainsi que l'ancien Spoutnik ont été supprimés. Le nouveau Spoutnik a ensuite été inséré.
Je l'ai fait ici pour vous donner un exemple, mais je rappelle que c'est une très mauvaise idée de donner soi-même un id
lorsque la colonne est auto-incrémentée (ce qui sera presque toujours le cas).
LOAD DATA INFILE
REPLACE est également disponible avec LOAD DATA INFILE. Le comportement est exactement le même.
Bien entendu, IGNORE et REPLACE ne peuvent pas être utilisés en même temps. C'est l'un ou l'autre.
Syntaxe
Code : SQL
LOAD DATA [LOCAL] INFILE 'nom_fichier' REPLACE
-- se place au
même endroit que IGNORE
INTO TABLE nom_table
[FIELDS
[TERMINATED BY '\t']
[ENCLOSED BY '']
[ESCAPED BY '\\' ]
]
[LINES
[STARTING BY '']
[TERMINATED BY '\n']
]
[IGNORE nombre LINES]
[(nom_colonne,...)];
Partie 2 : Index, jointures et sous-requêtes
145/414
www.openclassrooms.com