# Backend development

---

## Overview

+ Architecture serveur
+ Types de base de données
+ Base de données relationnelles

---

### Architecture Serveur

![[Pasted image 20250312154125.png]]

--

### Reverse proxy

![[Pasted image 20250312154343.png]]

+ Résoud les requêtes (routing)
+ Load balancing
+ Cryptographie et certificats

--

### Web server

![[Pasted image 20250312155058.png]]

+ Le moteur écoute les requête, sérialise les réponses, gère les imprévus, fait tourner le code de l'API
+ l'API est la partie programmable du serveur, la plaque tournant de la logique 

--

### Stockage

![[Pasted image 20250312155847.png]]

+ Base de données
+ Permet une structuration efficace  et performante des données 
+ Peut être versionnée, backupé, migré

--

### BDD relationnelles (schemafull)

![[Pasted image 20250312155847.png]]

+ Extrêmement polyvalentes et performantes
+ ACID (atomicity, consistency, isolation, and durability)
+ difficiles à scale

--

### BDD Document (schemaless)

![[Pasted image 20250312161605.png]]

+ Données structurées de manière plus flexible
+ Manipulées comme du JSON, naturel à utiliser depuis l'OO
+ plus facile à aborder et à scale initialement
+ Non ACID

--

### BDD Clé-valeur

![[Pasted image 20250312161701.png]]

+ Un genre de gros dictionnaire en mémoire vive
+ Performance++
+ Souvent utilisé comme cache pour les données fréquemment lues
+ Ou pour des usages répétés mais relativement simples

--

### BDD en graph

![[Pasted image 20250312161743.png]]

+ Données fortement interconnectées (type réseau social)
+ Les relations entre les éléements ont autant d'importance que les éléments eux-mêmes

---

## BDD Relationnelles

![[Pasted image 20250312162226.png]]

+ Polyvalence extrême
+ Toujours ce qu'il se fait de mieux depuis 1970

--

### Tables

![[Pasted image 20250312162333.png]]

+ Une table représente généralement un genre d'entité (ici, Customer)
+ On divise la table en colonnes (columns, des attributs) et en lignes (rows, des entrées dans la BDD)
+ Chaque row doit avoir un moyen unique de la différencier du reste, ce qu'on appelle une Primary Key (PK)
+ une PK peut être simple ou composite

--

### Relations

![[Pasted image 20250312162724.png]]

+ Les tables peuvent être mises en relation
+ Quand une PK est référencée dans une autre table comme un attribut, on parle alors de Foreign Key (FK)

--

### One to one

![[Pasted image 20250312163059.png]]

+ On peut avoir deux tables différentes qui se référencent par une FK dont on force l'unicité
+ On s'assure ainsi qu'un pays a un seul représentant et que ce représentant ne soit pas associé à d'autres pays

--

### One to many

![[Pasted image 20250312162724.png]]

+ Quand la FK n'est pas unique, on peut avoir plusieurs rows qui ont la même valeur en FK
+ Une classe n'aura qu'un seul professeur, mais un professeur peut enseigner plusieurs classes différentes

--

### Many to many

![[Pasted image 20250312163446.png]]

+ Quand on décrit une représentation many-to-many, on utilise une table de jointure pour s'assurer de la cohérence des entrées
+ La PK de la table de jointure peut-être simple (ID) mais souvent composite (les deux FK couplées)
+ Un étudiant accède à plusieurs classes, et les classes ont plusieurs étudiants qui y viennent

--

### Schema

![[Pasted image 20250312163825.png]]

+ La représentation de ces tables et de leurs relations forme le schema

--

### Interactions