Skip to content

database.md

Latest commit

 

History

History
71 lines (54 loc) · 2.54 KB

database.md

File metadata and controls

71 lines (54 loc) · 2.54 KB
Raw

Documentation de la Base de Données

Ce document présente l'architecture de la base de données MariaDB utilisée par le Job Aggregator, incluant le stockage des vecteurs pour l'IA.

1. Schéma Conceptuel (ERD)

erDiagram
    ROLES ||--o{ USERS : "possède"
    USERS ||--o{ REFRESH_TOKEN : "génère"
    OFFERS ||--o{ OFFER_SKILLS : "contient"
    SKILLS ||--o{ OFFER_SKILLS : "appartient à"

    USERS {
        string id PK
        int id_roles FK
        string pseudo
        string email
        string password
        string salt
    }

    OFFERS {
        string id PK
        string title
        string company_name
        text description_full
        vector embedding "1024 dimensions"
        int salary_min
        int salary_max
    }

    SKILLS {
        int id PK
        string name
    }
Loading

2. Choix Techniques

A. Pourquoi MariaDB ?

  • Performance : MariaDB offre une gestion robuste des index.
  • Recherche Vectorielle : Utilisation de l'extension vectorielle pour stocker et comparer les "embeddings" générés par le modèle BGE-M3. Cela permet une recherche sémantique (ex: trouver un job "Dev Frontend" quand on cherche "React").

B. Intégrité des Données

  • Clés Étrangères : Utilisation systématique de FOREIGN KEY avec ON DELETE CASCADE (ex: pour refresh_token et offer_skills) pour garantir qu'aucune donnée orpheline ne reste en base.
  • Contraintes d'Unicité : Les emails et pseudos sont UNIQUE pour éviter les doublons de comptes.
  • Index Full-Text : Indexation des colonnes name, lastname, pseudo et email pour des recherches textuelles rapides sur les utilisateurs.

3. Structure des Tables Clés

Table offers

C'est le cœur de l'agrégateur. Elle stocke les données normalisées provenant de WeLoveDevs.

  • embedding : Type VECTOR(1024). Stocke la représentation mathématique de l'offre pour le RAG.
  • salary_min/max : Stockés en entiers pour permettre des filtres numériques précis (supérieur à, entre, etc.).

Table offer_skills

Table de liaison permettant de lier une offre à plusieurs compétences techniques, optimisant ainsi les filtres par stack technologique.

4. Persistence

  • La base de données est persistée via un volume Docker (db_job).
  • Le volume est monté sur /var/lib/mysql, garantissant que les données survivent à un redémarrage ou une suppression des conteneurs (docker compose down).
  • Le schéma est initialisé automatiquement via config/db/schema.sql lors de la première création du conteneur.