Types de base de données
Une base de données, ou BdD, est un service qu'on utilise côté serveur pour stocker des informations afin de les utiliser par la suite. Exemple : les utilisateurs, une liste d'articles, des messages envoyés via un formulaire... Le service qu'on utilise pour gérer la base de données s'appelle un Système de Gestion de Base de Données ou SGBD.
Il existe deux grandes familles de SGBD : SQL et noSQL.
SQL
Le SQL est, en plus d'être un type de SGBD, un langage informatique. Le but de ce dernier est de faire des requêtes dans notre base de données. Les relations entre les tables sont la force des SGBD de type SQL. Exemple : un projet de blog qui a une table pour les articles et une table pour users. La table pour les articles comportera une colonne qui stockera un identifiant unique renvoyant vers un auteur. Il est alors facile de retrouver tous les articles d'un même auteur via une simple requête SQL, car dans ce type de SGBD, les tables sont fortement liées. Sous certaines conditions, il est, par exemple, impossible de supprimer un auteur si son identifiant est utilisé dans un article.
Sur cette impression écran, on voit deux tables qui sont fortement liées. Dans la table articles, la colonne préfixée par FK (Foreign Key) va stocker l'identifiant ou Primary Key ou PK de la table users.
Si l'on prend l'exemple ci-dessus, on voit que dans la table users (celle du bas) il y a deux utilisateurs enregistrés et dans la table articles (celle du haut) il y a quatre entrées, donc quatre articles. Chaque ligne des deux tables a un numéro d'identifiant qui est unique (colonne id). Pour ce qui est de la liaison, si l'on regarde la colonne author dans la table du haut, on voit que les articles 1, 2 et 4 sont écrits par John Doe (identifiant 1) et que l'article 3 a été écrit par Jane Doe (identifiant 2).
noSQL
Le noSQL intervient dans deux cas principaux :
- Comme on vient de le voir, le SQL est très puissant en ce qui concerne les relations entre les tables. Le souci est que pour créer les tables, qui vont constituer la base de données, on doit faire une description très détaillée de chaque colonne et du type de données qui vont y être stockées. Parfois il est nécessaire d'avoir un système plus libre et moins rigide.
- Quand on a un très gros volume de données, l'indexation est plus puissante dans les SGBD de type noSQL, ce qui permet de faire des requêtes plus performantes dans ces bases très chargées.
Le noSQL peut englober différentes familles de SGBD : Clé/Valeur, colonnes, documents, graphes.
Les clés
Clé primaire - PK
En anglais, on parle de primary key abrégée PK. La clé primaire correspond à une ou plusieurs colonnes qui vont permettre de discriminer une ligne au sein d'une table.
Dans la description de la table users on voit que la colonne id est la PK. Chaque utilisateur a un nombre différent, ils sont donc discriminés par cette colonne. Si l'on fait une requête où l'on souhaite trouver un utilisateur spécifique, on filtrera via la colonne id.
Une clé primaire peut aussi être composite, c'est-à-dire qu'elle va être composée non pas de la valeur d'une colonne mais de celle de plusieurs.
Si l'on regarde cette impression écran, on voit que la clé primaire de la table concerts est composée de la colonne place_id et de la colonne band_id. Elle permet d'indiquer les dates de concerts en liant, d'un côté, la table places pour avoir le lieu du concert, et de l'autre, la table bands pour avoir le groupe qui jouera à ce concert, c'est la somme des deux colonnes qui correspondra à la PK.
Clé étrangère - FK
En anglais, on parle de foreign key abrégée FK. Une clé étrangère est la liaison avec la clé primaire d'une autre table.
Reprenons les exemples ci-dessus.
Dans la description de la table articles, on voit que la FK est la colonne author. Cette dernière va pointer vers la PK de la table users.
Dans l'exemple ci-dessus, on a la clé composite qui correspond aux colonnes band_id et place_id, ces deux colonnes forment une clé primaire composite, mais chacune de ces colonnes est également une clé étrangère, qui pointe chacune vers une autre table.
Liaisons dangereuses
one-to-one
Une relation one-to-one correspond à une relation où une entrée de la table 1 ne peut être liée qu'à une seule entrée de la table 2 et une entrée de la table 2 ne peut être liée qu'à une seule entrée de la table 1. Exemple :
Un utilisateur ne peut avoir qu'un seul ensemble de contact (adresse + numéro de téléphone) et cet ensemble de contact ne peut être lié qu'à un seul utilisateur.
Dans ce cas, la table 1 ET/OU la table 2 peuvent porter la liaison. On pourrait très bien imaginer les cas d'usage suivants :
...ici ce n'est plus contact_infos mais users qui porte la relation (la FK est dans la table users), ou...
... ici ce sont les deux tables qui portent la relation, chaque table à une FK.
Dans ce type de relation, on choisit le côté selon celui qui nous paraît le plus logique, il n'y a pas de règle absolue.
one-to-many
Une relation one-to-many correspond à une relation où une entrée de la table 1 peut être liée à plusieurs entrées de la table 2, mais une entrée de la table 2 ne peut être liée qu'à une seule entrée de la table 1. Exemple :
Dans cette relation, un utilisateur peut être l'auteur de plusieurs articles, mais un article ne peut avoir qu'un seul auteur (choix fait lors de la création de la BdD, on pourrait imaginer dans un autre projet une relation many-to-many si un article à plusieurs auteurs).
Dans le cas d'une relation one-to-many, seul le côté one peut porter la relation. Dans notre exemple, seule la table articles peut porter la relation. En effet, si l'on voulait inverser le porteur de la relation, comme un utilisateur peut être l'auteur de plusieurs articles, la colonne articles ne serait pas une FK mais un tableau de FK, ce qui n'est pas dans l'esprit de SQL.
many-to-many
Une relation many-to-many correspond à une relation où une entrée de la table 1 peut être liée à plusieurs entrées de la table 2 et une entrée de la table 2 peut être liée à plusieurs entrées de la table 1. Exemple :
Un groupe peut jouer dans plusieurs lieux et un lieu peut accueillir plusieurs groupes.
Dans la relation many-to-many, on ne peut plus se contenter de garder deux tables. Pour la même raison que celle évoquée dans la partie one-to-many, comme chaque entrée de la table 1 peut être liée à plusieurs entrées de la table 2 et vice-versa, dans chacune d'entre elles, on ne pourrait avoir qu'un tableau de FK et non une FK simple. Pour résoudre ce problème, on utilise une table intermédiaire ou table de liaison. Cette table portera au minimum deux colonnes qui correspondront aux deux FK pour les deux côtés de la relation. Dans notre exemple, on se sert de cette table intermédiaire pour ajouter une information supplémentaire, qui est la date du concert, mais ce n'est pas une obligation, on aurait pu se contenter des deux FK.
Type de colonnes
Les types peuvent être très nombreux, et des nouveaux apparaissent parfois, par exemple, au moment où j'écris pour MariaDB les types listés sont ceux-ci. Pour cette indroduction, je ne parlerai que des plus simples et les plus utilisés quand on débute.
VARCHAR
Chaîne de caractères à longueur variable.
INT ou INTEGER
Un nombre entier allant de -2147483648 à 2147483647.
BOOL ou BOOLEAN
Un booléan valant 0 ou autre chose, 0 = false et autre chose = true. Quand on laisse la BdD gérer, elle stockera 0 ou 1.
TEXT
Une chaîne de caractères pour stocker du texte long. Par exemple, le titre de ce chapitre est stocké en VARCHAR et le contenu du chapitre est stocké en TEXT dans ma BdD.
DATETIME
Une date au format : YYYY-MM-DD hh:mm:ss.ms + hh:mm.
- ms = millisecond
- + hh:mm correspond à la différence avec l'heure GMT. Si l'on a une date, qui est stockée en + 01:00 on est à GMT+1