Stocker des tableaux dans MySQL

1. Les faux tableaux en tant que relations pour stocker des tableaux dans MySQL
2. Stocker des tableaux dans un type de données SQL différent

Ce tutoriel vous montre comment stocker ou simuler des tableaux en tant que champ dans MySQL.

SQL ne supporte pas explicitement les tableaux comme type de données dans son propre langage, mais il existe de nombreuses solutions de contournement pour le rendre possible car il s’agit d’une base de données relationnelle.

Les bases de données relationnelles comme SQL fonctionnent à l’aide de relations et de clés. La plupart du temps, nous utilisons ces relations pour relier plusieurs valeurs à une seule ligne à laquelle elle est liée.

Les relations sont une version découplée des tableaux, et cela fonctionne bien avec la nature et la conception du SQL (voir normalisation). C’est pourquoi il n’y a pas de type de données de tableau dans le SQL car, le plus souvent, les tableaux ne sont pas nécessaires car des relations existent.

Les tableaux dans une base de données peuvent être dangereux s’ils sont mal utilisés ou mal manipulés. Vous pouvez implémenter votre base de données sans eux et avoir une base de données très optimisée.

Si vous voulez ou devez vraiment stocker des tableaux, voici quelques moyens de le faire.

Les faux tableaux en tant que relations pour stocker des tableaux dans MySQL

Si nous devons suivre la nature et la convention du SQL, alors les tableaux doivent être traités comme des relations.

Disons que nous avons un customer qui a plusieurs order dans un restaurant.

Tout d’abord, nous créons des tableaux customer et order.

CREATE TABLE customer (
`id` INT NOT NULL PRIMARY KEY,
`name` VARCHAR(50)
);

CREATE TABLE order (
`order_id` INT NOT NULL PRIMARY KEY,
`order` VARCHAR(40),
`price` DOUBLE
);

Le client et ses commandes présentent un un-à-plusieurs relation ; pour que cela soit mis en œuvre, nous aurions besoin d’une entité associative pour relier les deux tables entre elles.

CREATE TABLE customer_order (
`customer_id` INT NOT NULL,
`order_id` INT NOT NULL,
PRIMARY KEY(`customer_id`, `order_id`)
);

Imaginons que les tables soient peuplées en tant que telles :

• customer

• order

• customer_order

À partir de ces tableaux, nous pouvons relier John Doe qui commande des coquilles Saint-Jacques, du homard et du gâteau au fromage. Pendant ce temps, Jane Doe a commandé un steak et un cheesecake.

Si nous voulons obtenir tout ce que John Doe a commandé, nous utiliserons simplement une requête SELECT JOIN comme telle :

SELECT c.name, o.order
FROM customer c
INNER JOIN customer_order co
ON co.customer_id = c.customer_id
INNER JOIN order o
ON o.order_id = co.order_id
WHERE name = 'John Doe'

La requête générera ce résultat :

Essentiellement, les relations sont des versions SQL de tableaux. Donc, si vous voulez un jour maintenir une bonne conception, comprenez le concept de relations, et utilisez-les autant que possible.

Stocker des tableaux dans un type de données SQL différent

Depuis la mise à jour de MySQL 5.7, le langage supporte désormais le [JSONps://dev.mysql.com/doc/refman/5.7/en/json.html) comme type de données. JSON fournit au SQL une méthode pratique pour stocker des types de données complexes comme des tableaux, des ensembles, des cartes, des dictionnaires et bien d’autres.

Le moyen le plus rapide de simuler un tableau dans le langage SQL est de le stocker sous forme de chaîne de caractères.

Créez des tableaux customer et order.

CREATE TABLE customer (
`id` INT NOT NULL PRIMARY KEY,
`name` VARCHAR(50),
`order` VARCHAR(999)
);

CREATE TABLE order (
`id` INT NOT NULL PRIMARY KEY,
`order` VARCHAR(50),
`price` DOUBLE
);

Chaque fois qu’un client passe une commande, utilisez GROUP_CONCAT() pour stocker une nouvelle entrée dans le champ order du client.

UPDATE customer
SET order = CONCAT(order, ', Cheesecake');

UPDATE customer
SET order = CONCAT(order, ', Ravioli');

Si vous interrogez le client avec les commandes, le résultat s’affichera :

Cette méthode est essentiellement un type de tableau stocké dans une seule colonne. Cependant, cela signifierait que vous ne suivez pas la convention d’une base de données relationnelle, ce qu’est le SQL.

C’est un moyen efficace de stocker un tableau au sein de SQL. Cependant, il est considéré comme une mauvaise conception de forcer un tableau dans une base de données relationnelle alors que vous pouvez facilement le stocker dans un nouveau tableau et configurer les relations et les contraintes.