FAQ MySQLConsultez toutes les FAQ

• Les accents : normalement, le charset par défaut prend en charge les accents, dans le cas contraire on peut spécifier un jeu de caractères au démarrage du serveur avec l'option --default-character-set. La commande show variables like 'character_set%' donne des informations intéressantes sur les charsets utilisés, le répertoire où ils se trouvent, etc.
  
  Si les champs sont destinés à être affichés dans des pages Web, on peut aussi remplacer les accents par leur équivalent HTML : é ... Attention cependant à bien convertir les accents lors des recherches dans la base.
  

• Apostrophes (quotes) : dans une requête SQL, ils doivent être échappés par un antislash : \' ou doublés : '' pour ne pas être confondus avec les quotes délimiteurs de chaîne. Cf la liste des caractères à échapper : http://dev.mysql.com/doc/mysql/en/String_syntax.html.
  

Une collation permet de spécifier, à l'intérieur d'un jeu de caractères, un ordre de tri et des équivalences entres caractères lors de la recherche.
Il devient alors possible de retrouver "Leïla" avec cette simple requête :

SELECT nom FROM personne WHERE nom="Leila"

• Pour : la gestion des uploads est simplifiée. Il n'y a pas de problèmes de droits en lecture ou écriture sur les répertoires, pas de sauvegarde des fichiers à faire, pas de risque d'incohérence entre les fichiers stockés sur le disque et leurs chemins répertoriés dans la base.
  

• Contre : la base de données risque d'être très sollicitée en cas de gros fichiers. Pour ne pas la surcharger, on préfèrera stocker uniquement le chemin de l'image dans un champ de type varchar. De plus les images seront facilement accessibles via un simple URL.
  

Oui : DBDesigner ( http://www.fabforce.net/dbdesigner4/) sous licence GPL, mais qui n'est plus maintenu ou encore Case Studio (commercial) : http://www.casestudio.fr.
Désormais, MySQL fournit un ensemble d'outils pour afficher des schémas ( MySQL Workbench) ou construire graphiquement des requêtes ( MySQL Query Browser).

Consultez la page outils MySQL pour plus d'informations.

MySQL peut adopter un comportement différent durant une session, en fonction de la configuration de ses modes SQL.

Ces modes peuvent être définis de trois manières :

• Au démarrage avec l'option --sql-mode="modes"
• En modifiant la variable globale sql_mode (SET GLOBAL sql_mode='modes')
• En modifiant la variable de session sql_mode (SET SESSION sql_mode='modes')
  

Dans le modèle relationnel, une table est un ensemble, il n'y a donc pas d'ordre de ses éléments. Selon une métaphore courante, il n'y a pas plus d'ordre des lignes dans une table que d'ordre des billes dans un sac.

Dans la pratique, cela veut dire que l'ordre n'est pas significatif, et donc que le SGBD est libre de placer les lignes dans l'ordre qui l'arrange.
Comme de nombreux SGBD, MySQL insère donc les lignes dans l'ordre chronologique.
Néanmoins, quand une ligne est supprimée, il se contente de la marquer comme "trou", sans décaler les suivantes.
A la prochaine insertion, MySQL comblera ce trou avec les nouvelles données, et l'ordre chronologique ne sera plus respecté.

Petite démonstration :

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
CREATE TABLE testtri ( 
 id int AUTO_INCREMENT PRIMARY KEY, 
 lib varchar(255) 
) ; 
  
INSERT INTO testtri (lib) VALUES ('titi') ; 
INSERT INTO testtri (lib) VALUES ('tata') ; 
INSERT INTO testtri (lib) VALUES ('toto') ; 
  
SELECT * FROM testtri ; -- ordre chronologique correct  
  
DELETE FROM testtri WHERE id = 2 ; 
  
INSERT INTO testtri (lib) VALUES ('bidule') ; 
  
SELECT * FROM testtri ; -- ordre chronologique incorrect

PHP a besoin qu'on échappe les backslashes (caractère \). Donc quand on lui envoie <br\\\\>, il lit <br\\>, et le transmet à MySQL.

MySQL a également besoin qu'on lui échappe les backslashes. Donc, quand il reçoit <br\\> de PHP, il lit <br\>. A l'inverse, si PHP lui envoie <br\>, il considère que \> est un > échappé, donc il lit <br>.