Discussion :

[laurentSc]

Bonjour,

je conçois une application qui va gérer une bdd. J'ai d'abord conçu l'architecture de la bdd. Maintenant, je souhaite concevoir l'architecture en POO qui me permettra de la gérer.
La question que je me pose : dans la bdd, j'ai utilisé la notion d'héritage.

La table mère :

Code sql :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
CREATE TABLE PL_platform(
   PL_ident INT UNSIGNED  AUTO_INCREMENT,
   platform VARCHAR(30) NOT NULL,
   platformowner VARCHAR(30) NOT NULL,
   PRIMARY KEY(PL_ident)
);

La table fille :

Code sql :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
CREATE TABLE AP_application(
   PL_ident INT UNSIGNED,
   AP_ident INT UNSIGNED AUTO_INCREMENT,
   appli_name VARCHAR(30) NOT NULL,
   publisher VARCHAR(30) NOT NULL,
   PRIMARY KEY(PL_ident, AP_ident),
   UNIQUE(AP_ident),
   UNIQUE(appli_name),
   FOREIGN KEY(PL_ident) REFERENCES PL_platform(PL_ident)
);

Maintenant, je veux concevoir le code PHP qui gérera cette bdd (SGBD = MySQL). Comme j'utilise la POO, je pense créer une classe PHP pour chaque table SQL. C'est là que je coince. Vais-je utiliser aussi le mécanisme d'héritage POO avec une classe mère du style class Platform avec pour propriétés

Code php :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
public $platform;
public $platformowner;

puis comme classe fille class Application extends Platform avec pour propriétés

Code php :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
public $appli_name ;
public $publisher ;

Autrement dit, reproduire uniquement les données informatives mais ne pas s'occuper des données techniques comme la clé étrangère ?

[grunk]

La notion d'héritage n'existe pas en SQL. Ce sont des relations. Pour parler d'héritage il faudrait qu'une table A récupère les champs d'une table B ce qui n'est pas possible, donc rien à voir.
Ici une table A va dépendre d'une table B ce qui n'est pas du tout la même chose.
En terme de conception (de code) on appel ca une composition => l'une des classe ne peut pas vivre sans l'autre.

Concernant ta conception , tu as 2 grandes écoles :

- Soit tu fais une modélisation complète , donc une classe par table + des classes de requétage/manipulation des données. Le tout ne retourne que des objets. C'est conceptuellement plus juste , mais plus long et plus lourd. (c'est la que les ORM entrent en jeu)
- Soit tu ne fais que des classes de requêtage qui vont retourner les données généralement sous forme de tableaux. Plus rapide et facile à utiliser mais moins "porpre".

Donc dans ton exemple tu aurais probablement quelque chose comme ca :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
class Platform
{
    private int $id;
    private string $plateform;
    private string $platformowner;
}
 
class Application
{
    private Platform $platform;
    private int $id;
    private string name;
    // etc
}

Quand on veux travailler comme ca , en général on ne réinvente pas la roue et on passe par un ORM (doctrine par exemple) qui va s'occuper de toute la complexité

[laurentSc]

En effet, quand je parlais d'héritage dans les bdd, il s'agit en fait d'une relation avec une clé étrangère...

Bon, je ne connais pas du tout Doctrine. Peux-tu m'indiquer un tuto (abordable) ?

[grunk]

Je ne pourrais pas te conseiller de tuto , je n'utilise pas d'ORM. Je trouve ca trop peu performant pour le gain que ca apporte.

[laurentSc]

Ah bon, alors plutôt qu'apprendre (je ne sais trop comment) un nouvel outil, je pense coder tout par moi-même, et probablement, revenir ici...