Autres fonctionnalités

1. Intérêt et limitations

Le partitionnement horizontal permet de diviser une table en fonction des données qu’elle contient, de manière transparente pour l’utilisateur. Ce processus peut permettre une gestion plus efficace des données stockées en les regroupant dans différents emplacements (partitions) selon certains critères. Le partitionnement d’une table se définit à sa création, en indiquant le type et la clé de partitionnement, ainsi que d’autres paramètres tels que le nombre de partitions à générer.

1. Rôle

Les routines stockées sont des programmes (des procédures ou des fonctions) créés par l’utilisateur, précompilés et stockés dans le serveur MariaDB. Elles permettent de déplacer une partie de la logique métier d’une application du client vers le serveur. Le client n’a alors plus besoin de soumettre à nouveau toute la commande, mais doit simplement faire une simple référence à la routine.

Les routines stockées présentent plusieurs avantages :

Le langage permettant de programmer une routine est assez rudimentaire, mais il est possible d’utiliser :

Lors de la création d’un programme stocké (procédure, fonction, trigger...), il est impératif de modifier le délimiteur, c’est-à-dire le symbole qui indique à...

1. Rôle

Les déclencheurs ou triggers sont des objets dont le but est d’exécuter du code en réaction à un événement qui survient sur une table. Les événements peuvent être de trois types : INSERT, UPDATE ou DELETE (ou assimilés, par exemple, l’instruction REPLACE qui vaut soit INSERT, soit INSERT et DELETE). L’ordre de déclenchement est défini avant (BEFORE) ou après (AFTER) l’événement. Par exemple, le DBA choisira BEFORE pour un test de vérification sur des données et AFTER pour de la journalisation.

2. Syntaxe

La syntaxe à observer lors de la création d’un déclencheur est :

CREATE  
[DEFINER = { user | CURRENT_USER }]  
TRIGGER nom_du_trigger moment_du_déclenchement  
action_qui_déclenche  
ON nom_de_table FOR EACH ROW corps_du_déclencheur
 

avec moment_du_déclenchement qui vaut BEFORE ou AFTER et action_qui_déclenche qui prend les valeurs INSERT, UPDATE ou DELETE.

Dans le corps du déclencheur, les alias OLD et NEW sont disponibles en fonction du contexte (INSERT/UPATE/DELETE). Ils permettent d’accéder respectivement à la valeur d’une colonne de la table qui contient le déclencheur, avant et après modification :

Exemple d’un trigger qui sauvegarde les données effacées de la table City :

CREATE...

1. Rôle

Le planificateur d’événements ou « event scheduler » offre la possibilité à l’administrateur de bases de données de déclencher l’exécution de programmes stockés directement sur le serveur MariaDB. Ce planificateur de tâches interne (CRON-like) permet donc d’automatiser très simplement des tâches à des intervalles réguliers, ou à heure fixe, sans avoir besoin de configurer le système d’exploitation qui héberge la base de données.

Pour pouvoir l’utiliser, il faut tout d’abord l’activer, car ce n’est pas le cas par défaut :

mysql> SHOW VARIABLES LIKE 'event_scheduler';  
+-----------------+-------+  
| Variable_name   | Value |  
+-----------------+-------+  
| event_scheduler | OFF   |   
+-----------------+-------+  
  
mysql> SET GLOBAL event_scheduler = 1;  
  
mysql> SHOW VARIABLES LIKE 'event_scheduler';  
+-----------------+-------+  
| Variable_name   | Value |  
+-----------------+-------+  
| event_scheduler | ON    |   
+-----------------+-------+ 
 

Une fois activé, MariaDB démarre un processus léger (thread) en tâche de fond. Ce processus est chargé d’exécuter les événements lorsque le moment est venu. Vous pouvez le constater en utilisant la commande SHOW PROCESSLIST, et, pour cela, vous aurez besoin du privilège SUPER, sinon vous ne verrez que les processus qui vous sont associés :

mysql> SHOW PROCESSLIST\G  
*************************** 1. row *************************** 
     Id: 12   
   User: event_scheduler   
   Host: localhost   
     db: NULL   
Command: Daemon   ...

1. Rôle

Les vues sont des tables virtuelles créées à partir d’une requête SELECT. Elles ne stockent pas les données qu’elles génèrent mais seulement la requête permettant de les créer. La requête SELECT qui génère la vue référence une ou plusieurs tables. La vue peut donc être par exemple une jointure entre différentes tables, l’agrégation ou l’extraction de certaines colonnes d’une table. Elle peut également être créée à partir d’une autre vue.

Les vues sont souvent en lecture seule et ne permettent donc que de lire des données. Cependant, MariaDB permet la création de vues modifiables sous certaines conditions :

Les vues peuvent être utilisées pour différentes raisons, elles permettent de :

1. Introduction

Les colonnes générées sont apparues avec MariaDB 5.2, soit très longtemps avant MySQL. L’idée est très simple : il s’agit de colonnes dont les valeurs sont dérivées d’une ou plusieurs autres colonnes de la même table. Les colonnes générées peuvent être indexées, ce qui permet d’ajouter des index fonctionnels pour, par exemple :

MariaDB propose deux types de colonnes générées : les colonnes virtuelles, dont les valeurs sont calculées à la volée et jamais stockées sur disque, et les colonnes persistantes, qui sont des colonnes classiques stockées sur disque mais dont la valeur est calculée à partir d’autres colonnes.

2. Colonnes persistentes

Imaginez que vous avez une table t avec une colonne stockant un nom de famille. Pour ajouter à votre table une colonne persistente contenant le nom de famille à l’envers, vous utiliserez la syntaxe suivante :

mysql> ALTER TABLE t ADD nom_inverse VARCHAR(50) GENERATED ALWAYS AS (REVERSE(nom)) PERSISTENT;...