5.3 Functionalités manquantes

Les fonctionnalités suivantes manquent dans la version courante de MySQL. La liste des fonctionnalités classées par ordre de priorité est disponible en ligne à : F Liste de voeux pour les versions futures de MySQL (la TODO).

5.3.1 Sub-select

La requête suivante ne fonctionne par encore sous MySQL:

SELECT * FROM table1 WHERE id IN (SELECT id FROM table2);
SELECT * FROM table1 WHERE id NOT IN (SELECT id FROM table2);

Cependant, il est souvent possible de se passer d'une sous sélection :

SELECT table1.* FROM table1,table2 WHERE table1.id=table2.id;
SELECT table1.* FROM table1 LEFT JOIN table2 ON table1.id=table2.id where table2.id IS NULL

Pour les sous requêtes compliquées, vous pouvez toujours créer une table temporaire, et y appliquer votre requête.

MySQL ne supporte que INSERT ... SELECT ... et REPLACE ... SELECT ... Les sous sélections indépendantes ne seront disponibles qu'à partir de la version 3.24.0. Actuellement, vous pouvez toujours utiliser la fonction IN() dans d'autres contextes.

5.3.2 SELECT INTO TABLE

MySQL ne supporte pas encore cette extension du SQL Orable.: SELECT ... INTO TABLE .... A la place, MySQL supporte la syntaxe de la norme ANSI SQL INSERT INTO ... SELECT ..., ce qui est pratiquement la même chose.

Alternativement, vous pouvez utiliser SELECT INTO OUTFILE... ou CREATE TABLE ... SELECT pour résoudre votre problème.

5.3.3 Transactions

Les transactions ne sont pas encore supportées par MySQL. Le serveur va bientôt accepter des opérations atomiques, ce qui permettra des transactions, mais sans le rollback. Avec les opérations atomiques, vous pourrez exécuter des groupes de commandes INSERT/SELECT/ avec n'importe quelle commande, et être sur qu'il n'y aura aucune interférence avec un autre thread. Dans ce contexte, vous n'aurez alors pas besoin de rollback. Actuellement, vous pouvez empêcher les autres threads d'interférer en utilisant les fonctions LOCK TABLES et UNLOCK TABLES. LOCK TABLES.

5.3.4 Procédures stockées et triggers

Une fonctions enregistrée est un ensemble de commandes SQL qui peut être compilé et enregistré sur le serveur. Une fois fait, les clients peuvent se référer à cette fonction pour exécuter l'ensemble des commandes. Cela accélère le traitement des requêtes, car elles n'ont pas a être analysées, et moins d'information circule entre le client et le serveur. Il est aussi possible d'élever le niveau de conception, en btissant des bibliothèques.

Un trigger est une fonction enregistrée qui est invoquées à chaque fois qu'un événement particulier survient. Par exemple, vous pourriez installer une fonction qui sera lancée à chaque fois qu'un enregistrement sera effacé dans une table de transaction, pour effacer automatiquement les informations correspondantes dans les tables de clients.

Lors de modifications ultérieures, MySQL sera capable de gérer les fonctions enregistrées, mais pas les triggers. En général, les triggers ralentissent le serveur, même pour des requêtes pour lesquelles ils ne sont pas appelés.

Pour savoir quand MySQL disposera des procédures enregistrées, sinon, F Liste de voeux pour les versions futures de MySQL (la TODO).

5.3.5 Clés étrangères

Remarque : les clés externes en SQL ne sont pas utilisées pour effectuer des regroupements de table, mais pour assurer l'intégrité référentielle. Si vous voulez lire des informations depuis plusieurs tables avec une commande SELECT, c'est un regroupement !

SELECT * from table1,table2 where table1.id = table2.id;

JOIN. 8.3.5 Utiliser des clés étrangères

La syntaxe FOREIGN KEY de MySQL n'existe que pour la compatibilité avec les commandes CREATE TABLE des autres bases SQL : elle n'a aucun effet. La syntaxe FOREIGN KEY sans la partie ON DELETE ... n'est utilisée que pour des raisons de documentation. Certaines applications ODBC l'utilise pour générer des clauses WHERE automatiques, mais il est généralement simple à remplacer. FOREIGN KEY est parfois utilisé comme contrainte, mais ce genre de vérification n'est pas nécessaire si les lignes ont été insérées dans l'ordre. MySQL ne supporte que ces clauses, car certaines applications en ont besoin (qu'elle fonctionne ou pas).

Avec MySQL, vous pouvez contourner le problème sans la clause ON DELETE ... en ajoutant une commande DELETE adéquate lors de l'effacement d'un enregsitrement d'une table qui a une clé externe. En pratique, c'est aussi rapide (voire plus), et beaucoup plus portable que les clés externes.

Dans un futur proche, nous allons implémenter FOREIGN KEY de manière à sauver les informations dans la table de spécification, pour qu'elles soient accessibles par mysqldump et ODBC.

5.3.5.1 De bonnes raisons de ne pas utiliser les clés étrangères

Il y a tant de problèmes avec FOREIGN KEYs qu'on ne sait même pas par ou commencer :

• Les clés externes compliquent la vie, car les définitions des clés externes doivent être enregistrées dans une base de données, et les implémenter nous forcera à abandonner la gestion actuelle des tables (une table égale un fichier, qui peut être sauvé ou copié).
• L'impact sur la vitesse d'exécution de INSERT et UPDATE, et dans ce cas, presque toutes les vérifications dues à FOREIGN KEY ne servent à rien, car vous insérez les informations dans le bon ordre, naturellement.
• Les clés externes imposent l'utilisation de verrous sur de nombreuses tables, et cela peut conduire, par effet de domino, à geler toute la base. Il est beaucoup plus rapide d'effacer un enregistrement d'une table, puis de s'occuper des autres tables à la suite.
• Avec les clés externes, il n'est plus possible de reconstituer une table par un effacement complet, suivi d'un chargement de tous les enregistrements (depuis une nouvelle source, ou une sauvegarde).
• Avec les clés externes, il est impossible faire un dump d'une table, puis de la recharger, à moins de le faire dans un ordre très spécifique.
• Il est très facile de créer des références circulaires, qui sont autorisées, mais rendent impossible la recréation de la table à partir d'un enregistrement unique, même si la définition de la table fonctionne et est utilisable.

Le seul aspect intéressant de FOREIGN KEY est de donner aux clients ODBC et quelques autres la possibilité de voir comment une table est connectée, et de l'utiliser pour créer un diagramme de connexion lors de la création d'applications.

MySQL gérera prochainement les définitions des FOREIGN KEY, ce qui permettra aux clients de réclamer la structure de la connexion originale. La version courantes des fichiers ``.frm'' ne le permet pas.

5.3.6 Vues

MySQL ne supporte pas les vues, mais c'est sur la liste des fonctionnalités futures.

5.3.7 `--' comme début de commentaire

Sur d'autres bases SQL les commentaires commencent par ``--''. MySQL utilise ``#'' pour débuter un commentaire, même si mysql supprime aussi les lignes qui commencent par ``--''. Vous pouvez aussi utiliser le style de commentaires C /* Ceci est un commentaire */ avec MySQL. Comments.

MySQL n'accepte pas les commentaires commencant par ``--''; car ce style de commentaire obsolète a déjà causé de nombreux problèmes avec les requêtes générées automatiquement, lorsque la base utilise un code comme celui ci : la valeur de paiement va être placée à la place de !paiement!:

UPDATE nom_table SET credit=credit-!paiement!

Mais que ce passe t il si la valeur de paiement est négative?

Etant donné que 1--1 valide en SQL, nous pensons que les commentaires commencé par ``--'' sont une très mauvaise idée.

Si vous avez un programme SQL qui contient des commentaires avec le format ``--'' vous devriez utiliser:

shell> replace " --" " #" < Fichier-texte-avec-des-commentaires-zarbi | mysql database

A la place de l'habituel :

shell> mysql database < text-file-with-funny-comments.sql

Vous pouvez aussi utiliser la commande fichier ``in place'' pour remplacer les commentaires ``--'' par ``#'':

shell> replace " --" " #" -- text-file-with-funny-comments.sql

Retrouvez vos situation initiale avec :

shell> replace " #" " --" -- text-file-with-funny-comments.sql