inheritance Colum_aggregation vs Concrete

bonjour,
j' ai besoin de gérer un ensemble d'objet (asset) pour un utilisateur.
Chaque asset à des champs communs et certains ont des champs particuliers.
exemple:
User a un n° de télephone XXXX et un PC qui est un laptop marqueX modeleW

j'ai a la fois besoin d'avoir une vue synthétique de l'ensemble des asset pour une persone:
user1:
N° de telephone
PC

et une vue en détails:
PC de user 1: laptop, marqueX modeleW

pour cela j'ai tester l'inheritance de Doctrine.
Si au niveau visualisation le modele Column_aggregation me convient ( un generate-admin asset me donne une vue complete et un generate-admin pc me donne que les PC).
cela charge tout dans une même table, d’où des champs qui servent à rien pour beaucoup de ligne et une table énorme.
Si le modèle Concrete sépare les données dans des tables différentes je n'ai pas trouvé le moyen d'avoir la vue synthétique.
un generate admin asset me donne une liste vide.

Y a t il moyen avec le modèle concrete d'obtenir cette vue synthétique ?

Je ne pense pas qu'un héritage soit adapté à ton problème.

Pose ton schéma (MLD) tu devrais trouver des solutions plus appropriées.

en gros, pour un profil utilisateur, je gére un ensemble de 'bien', bien qui peut être physique (un PC) ou virtuel (compte mail, Id windows...).
Derrière chacun de ces biens je gère des données spécifiques et quelque fois un historique d'utilisation (ex, compte mail historique de taille).

Bien entendu l'ensemble de ces données viennent de fichier différents que j'ai besoin de croiser.
en objet, je dirait que j'ai un objet Asset avec un nom, un propriétaire.
et des objets PC, Tel, Compte mail, qui hérite de l'objet Asset.

Et pour un propriétaire j'ai besoin d'avoir l'affichage de l'ensemble de ces assets.

Donc tu as une table utilisateurs et une table biens...

Je vois trois possibilités pour gérer ton problème.

1) tu peux créer des héritages de la tables biens pour chaque type de bien. Ceci limite le nombre de type possible, charge la table et rend la création d'un nouveau bien difficile (il faut reprogrammer pas mal de choses).

2) tu peux utiliser un ensemble de table, une table propriétés des bien avec le num du lien, le type de propriété et la valeur, il faudra compléter par une table des types de biens et des propriétés gérées suivant le type avec éventuellement des paramètres à utiliser dans les form de saisie.

3) tu peux utiliser un champ propriété dans lequel tu vas parser les propriétés. On est très proche de la solution 1 avec moins de contraintes au niveau de la taille (nombre de champs) de la table.

Perso, je pense que la solution la plus souple est la 2, l'héritage de tables ne permettant pas de gérer simplement la modification ou la création d'un nouveau type.

j'ai aussi pensé à la solution 2, sauf que si au niveau modèle, c'est la moins contraignante, elle ne permet pas de profiter des aides de symfony. Il faudra créer presque à la mano les modules par type, et tout les getPropriétes().

j'ai initialement choisi la solution de l’héritage du fait que, d'un part mon nombre de type de bien ne bougera pas beaucoup et que cela me permet de profiter pleinement de la puissance de symfony.

En ayant une table abstraite Bien, je peut générer un module admin pour y lister tout les Biens avec leur propriétés communes.
En héritant de cette table les types de bien, je peut générer un module admin par type de bien.
L'ajout d'un type ne pose pas vraiment de problème, puisque j'ai juste a créer une table fille de Bien et a générer le module admin.
Seul bemol, c'est qu'avec l'option Column Aggregation, cela ne me crée qu'une table Biens et donc si je rajoute un type je devrai modifier puis recharger cette table. Mais bon avec un ALTER ça devrait le faire.

Je reste convaincu que la deuxième méthode est la meilleur.

Non, il ne faut rien créer "à la mano", il faut une table des types de propriétés qui va avoir les champs, type, validateur et autres. L'écran va se contenter de puiser dans cette table pour ce créer.

Quant au modification de structure de table sur une table existante, elle sont prise en charge dans le fonctionnement applicatif de symfony. Il faut utiliser les notions de migrate. Ce qui implique plusieurs version des tables et l'écriture d'un code spécifique pour les commandes sql.