Base de données¶

Cette page couvre le versant opératoire de la base de données de BCard : comment la connexion est configurée, comment les 20 entités du domaine sont réparties, et comment gérer les migrations et les jeux de données de développement. Pour la vue conceptuelle du modèle de données (regroupements fonctionnels, statuts métier), voir la section Modèle de données d'architecture.md — elle n'est pas reprise ici.

Configuration¶

BCard utilise Doctrine ORM sur MySQL. La connexion est portée par la seule variable DATABASE_URL, lue par config/packages/doctrine.yaml (voir Configuration → Base de données pour son format et un exemple neutre). Aucune valeur réelle de connexion n'est reproduite sur cette page : en développement, docker-compose.yaml définit un service MySQL avec des identifiants en clair qui ne servent qu'en local (voir Points de vigilance de la page Sécurité).

Les migrations Doctrine sont configurées par config/packages/doctrine_migrations.yaml : le seul réglage déclaré est le chemin des classes de migration, migrations/, sous le namespace arbitraire DoctrineMigrations (délibérément distinct de App\Migrations pour ne pas être autochargé) ; le profileur de migrations est désactivé (enable_profiler: false).

Entités¶

Vingt entités composent le domaine. Le tableau ci-dessous les couvre toutes ; le rôle métier et les statuts de chacune sont détaillés dans le Modèle de données d'architecture.md.

Comptes et organisations¶

Entité	Rôle	Relations principales
`User`	Compte applicatif (authentification, rôles, statut vérifié/activé)	`OneToMany` vers `Employee`, `OneToMany` vers `Subscription` (via `company` le cas échéant), rattachement optionnel à une `Company`
`Company`	Entreprise cliente	`OneToMany` vers `User`, `Employee`, `Subscription`, `Payment`, `CompanyActivity`
`Employee`	Employé d'une entreprise	`ManyToOne` vers `Company`, `OneToOne` (inverse) vers `BusinessCardAize`
`Activity`	Secteur d'activité de référence	`ManyToOne` inverse depuis `CompanyActivity`
`CompanyActivity`	Association entre une entreprise et un secteur d'activité	`ManyToOne` vers `Company`

Cartes et catalogue¶

Entité	Rôle	Relations principales
`Card`	Produit « carte physique » du catalogue	`ManyToOne` vers `CardModel`, `OneToMany` vers `OrderItem`, `BusinessCardAize`, `Payment`, `CardColorOption`, `CardPrintOption`
`CardModel`	Modèle graphique de carte proposé au catalogue	`OneToMany` vers `Card`
`CardColorOption`	Option de couleur personnalisable d'une carte	`ManyToOne` vers `Card`
`CardPrintOption`	Option d'impression personnalisable d'une carte	`ManyToOne` vers `Card`
`BusinessCardAize`	Carte de visite numérique (identifiée par `publicHash`)	`ManyToOne` vers `User`/`Employee`, `OneToOne` vers `Card`, `OneToMany` vers `Activity`
`PhysicalCard`	Exemplaire de carte physique commandé, avec cycle de fabrication	`ManyToOne` vers `User`, `BusinessCardAize`, `Card`, `CardModel`, `Order`

Contacts¶

Entité	Rôle	Relations principales
`Contact`	Entrée du carnet d'adresses (drapeau `isBCard` pour l'origine)	`ManyToOne` vers `User`

Commerce¶

Entité	Rôle	Relations principales
`Order`	Commande	`OneToMany` vers `OrderItem`, `Payment` ; `ManyToOne` vers `User`
`OrderItem`	Ligne de commande	`ManyToOne` vers `Order`, `Card`
`Payment`	Paiement rattaché à une commande ou un abonnement	`ManyToOne` vers `Order`, `Card`, `Company`, `Subscription` (toutes facultatives)
`Plan`	Offre d'abonnement (prix, fonctionnalités, cartes incluses)	`OneToMany` vers `Subscription`
`Subscription`	Abonnement souscrit	`ManyToOne` vers `Plan`, `Company`, `User`

Exploitation¶

Entité	Rôle	Relations principales
`RefreshToken`	Jeton de rafraîchissement de l'API mobile	`ManyToOne` vers `User` ; rattachement effectif par l'e-mail (`username`), pas par la relation Doctrine (voir Rafraîchissement)
`AuditLog`	Trace d'audit immuable d'une action sensible	`ManyToOne` (facultatif, `SET NULL`) vers `User` en cible et en acteur
`Settings`	Paramètres généraux modifiables depuis le back-office	`ManyToOne` vers `Card`

Migrations¶

Le projet utilise doctrine/doctrine-migrations-bundle. Au moment de la rédaction de cette page, le répertoire migrations/ contient 73 classes, la plus récente étant Version20260323090000.php.

Créer une migration¶

Après une modification des entités, générer une migration qui reflète le différentiel avec le schéma en base :

php bin/console make:migration
# ou, équivalent Doctrine natif :
php bin/console doctrine:migrations:diff

La classe générée est déposée dans migrations/, sous le namespace DoctrineMigrations configuré par config/packages/doctrine_migrations.yaml. Relire son contenu avant de l'appliquer : le différentiel généré peut inclure des changements non désirés (index, longueur de colonne) hérités de l'état réel de la base locale.

Appliquer les migrations¶

php bin/console doctrine:migrations:migrate

Sans argument, la commande exécute toutes les migrations non encore jouées, dans l'ordre de leur horodatage, jusqu'à la plus récente.

Revenir en arrière¶

php bin/console doctrine:migrations:migrate prev
# ou vers une version précise :
php bin/console doctrine:migrations:migrate <version>

doctrine/doctrine-migrations-bundle exécute la méthode down() de chaque migration traversée pour revenir en arrière ; cela suppose qu'elle a bien été implémentée dans la classe concernée.

Jeux de données de développement¶

Le projet déclare la dépendance doctrine/doctrine-fixtures-bundle et fournit deux classes de fixtures dans src/DataFixtures/ :

PlanFixtures — crée les trois plans d'abonnement de référence (Free, Pro, Entreprise), avec leurs prix, fonctionnalités et ordre d'affichage. Ne déclare aucune dépendance envers une autre fixture.
AppFixtures — squelette généré par Symfony Flex, laissé vide : son code d'exemple (entité Product) est commenté et n'a jamais été remplacé ; elle ne persiste rien.

Pour charger les fixtures disponibles :

php bin/console doctrine:fixtures:load

Cette commande vide au préalable les tables concernées (confirmation interactive sauf avec --no-interaction ou --append pour cumuler plutôt que remplacer).