Discussion :

[Bakura]

Bonsoir à tous ,

Tout d'abord je tenais à remercier les personnes qui m'ont aidé il y a de cela quelques mois. Leurs conseils m'ont été extrêmement précieux et j'ai pu apporter de nombreuses modifications à mon modèle de données.

Aujourd'hui, mon développement a bien avancé et c'est effectivement extrêmement pratique de travailler avec un schéma bien conçu, même si j'ai du dénormaliser à un endroit ou deux pour éviter certaines prises de tête de certaines requêtes.

Je souhaitais toutefois vous poser une question (qui n'est pas forcément que sur du conceptuel), puisqu'il reste un endroit de mon schéma pour lequel je ne suis pas à 100% satisfait (même si ça fonctionne très bien).

Il s'agit de la gestion des utilisateurs. J'ai deux types d'utilisateurs, qui partagent certaines informations communes (login, password...), et un discriminant qui me permet, lors de la récupération des données, de faire une jointure sur l'une des deux tables correspondant au type d'utilisateur.

Seulement, mes tables (et schéma) liées aux utilisateurs contiennent pas mal d'informations, mais j'ai rarement besoin de récupérer toutes ces informations, et il s'agit d'information de profil qui peuvent assez régulièrement ne pas être remplies (typiquement, le site internet, le twitter, le facebook, un numéro de téléphone...).

Je pense souvent à ajouter une entité "Profile" pour ces deux types d'utilisateurs, mais comme ça marche bien ainsi, je n'ai pas encore franchi le pas.

De manière générale, ma question est : y a t-il une raison à normaliser davantage un schéma d'utilisateurs (qui peuvent potentiellement contenir pas mal d'informations) ? Comment estimer où doit s'arrêter la normalisation d'un schéma ?

Merci !

[Richard_35]

Bonjour Bakura,

Je ne comprends pas trop ton souci : serait-il d'utiliser le "SELECT *" qui te ramène 1 milliard de champs non renseignés dont tu n'as que faire ?

[Bakura]

Exactement. J'hésite à créer une entité "Profil" pour chacune de mes deux entités pour contenir ces informations.

En fait, le soucis étant qu'au niveau de l'ORM, il est parfaitement déconseillé dans la documentation de récupérer des objets partiels (et donc de spécifier les colonnes que l'on souhaite récupérer), et que la manière courante est que l'ORM récupère toutes les colonnes (les relations étant chargées via un lazy-loading).

[Richard_35]

C'est bien ce qui me semblait... C'est au développement de se plier à la modélisation, et non l'inverse.

Effectivement, il est possible de créer :

Utilisateur -0,1---[Possèder]---(1,1)- Utilisateur_AttributsAnnexes

donnant :

Utilisateur(IdUtilisateur, Nom, [attributs que tu considères comme souvent renseignés])
Utilisateur_AttributsAnnexes(#IdUtilisateur, [attributs que tu considères comme pas souvent renseignés])

Mais, la frontière entre "souvent renseignés" et "pas souvent renseignés" est floue. Au moindre besoin d'un seul champ dans la seconde table, tu ramèneras l'ensemble des champs.
A moins de créer une autre table des "attributs moyennement renseignés"... d'où une gestion dangereuse des niveaux de renseignements... re .

Je te suggère de jeter un coup d'oeil sur cette discussion qui aborde l'histoire du bonhomme NULL et qui dispatche les attributs, non pas en termes d'information renseignée, mais en termes de clés étrangères : c'est là le "vrai débat", me semble-t-il.

[Bakura]

Merci pour le lien, c'est intéressant (bien que parfois un peu trop technique ;-)). Dans mon application, disons que la limite est au contraire assez bien définie.

J'affiche très peu d'informations concernant les utilisateurs (tout au plus nom, prénom, photo et nom d'entreprise). Les autres informations (site internet, compte Twitter...) ne sont affichés que lorsque l'on va sur la fiche d'un utilisateur (et dans notre système, c'est une action relativement rare), ou lors de la modification des attributs du profil.

Du coup, je pense que je vais créer deux entités Profil pour mes deux types d'utilisateurs... même si, sémantiquement, ça me gêne un peu de garder une information comme l'URL de la photo en dehors d'une éventuelle entitée "Profil" même si elle devrait en faire parti intrinsèquement).

De toute façon il me reste encore deux bons mois avant de tenter de plus ou moins figer mon schéma (j'espère ne rien avoir oublié :p...).

Merci de tes réponses en tout cas.

[CinePhil]

Comme sur une autre de tes discussions, probablement en rapport avec le même projet, ça commence bien :

c'est effectivement extrêmement pratique de travailler avec un schéma bien conçu

Mais ça continue mal :

même si j'ai du dénormaliser à un endroit ou deux pour éviter certaines prises de tête de certaines requêtes.

La dénormalisation est l'ultime solution à envisager lorsqu'on constate des soucis de performances qui ne sont pas solubles par d'autres méthodes (indexation notamment).

Dénormaliser a priori, et surtout pour causes de "prise de tête" sur certaines requêtes, est une très mauvaise idée !

En fait, le soucis étant qu'au niveau de l'ORM, il est parfaitement déconseillé dans la documentation de récupérer des objets partiels (et donc de spécifier les colonnes que l'on souhaite récupérer), et que la manière courante est que l'ORM récupère toutes les colonnes (les relations étant chargées via un lazy-loading).

Ça c'est encore une belle connerie de cette saloperie d'ORM !
Au contraire, pour les performances de l'application en communication avec une BDD, il vaut mieux éviter de relancer la guerre des étoiles !

Effectivement, il est possible de créer :

Utilisateur -0,1---[Possèder]---(1,1)- Utilisateur_AttributsAnnexes

donnant :

Utilisateur(IdUtilisateur, Nom, [attributs que tu considères comme souvent renseignés])
Utilisateur_AttributsAnnexes(#IdUtilisateur, [attributs que tu considères comme pas souvent renseignés])

Ce genre de modèle proposé par Richard ne se justifie que si on a un nombre variables d'attributs annexes entre les profils. Si tous les utilisateurs ont les mêmes attributs, évite ce modèle qui est plus complexe et moins performant à requêter.
Cependant, si les utilisateurs ne remplissent généralement pas tous les attributs de leur profil, afin d'éviter le peuplement de la table par le bonhomme NULL, c'est une solution qui peut être intéressante.

Comme je l'ai dit dans ton autre discussion :
1) On modélise les données rigoureusement ;
2) On implémente le modèle dans la BDD ;
3) On crée les vues nécessaires au programme qui constituent le modèle logique de données, qu'on peut aussi appeler le modèle objet ;
4) Jette l'ORM !
5) Le programme n'utilise que les vues.

[Bakura]

C'est effectivement toujours le même projet, qui avance bien d'ailleurs ;-).

Mais ça continue mal

Pardon .

Ça c'est encore une belle connerie de cette saloperie d'ORM !
Au contraire, pour les performances de l'application en communication avec une BDD, il vaut mieux éviter de relancer la guerre des étoiles !

Mais quel est cette haine contre les ORM ? ;-) Doctrine 2 est un plaisir à utiliser, il m'accélère quand même pas mal mon développement et dans le contexte d'une programmation objet, ça permet de garder un code quand même relativement propre. Etant le seul développeur du projet, c'est en tout cas une concession en terme de performance que je suis prêt à faire, sachant tous les avantages que cela m'apporte à côté (après, ça ne m'empêche pas de me poser certaines questions sur la démoralisation).

Quand à la guerre des étoiles je suis évidemment d'accord et, pour être honnête, la meilleure pratique au niveau de l'ORM serait de récupérer des tableaux de données read-only (plutôt que des objets) et ne récupérer que ce qui m'intéresse (en fait, l'ORM déconseille de récupérer des objets partiels car cela fragilise le code dans le sens ou tu as toujours accès à des méthodes avec des données non initialisées), problème qui n'existe pas avec un simple tableau.

Après, je tombe dans un soucis d'organisation (oui, je suis très très maniaque...), et la simple idée de créer potentiellement de nombreuses fonctions identiques mais retournant un nombre de champs différents me plaît moyennement (ça voudrait dire que j'aurais une fonction getByIdWithFirstName, getById, getByIdWithRelationship...). D'un point de vue maintenabilité, ça risque de devenir vite ingérable. Ou alors faudrait que je fasse en sorte de passer un tableau des champs que je souhaite récupérer. Ca ça serait à réfléchir.

Ce genre de modèle proposé par Richard ne se justifie que si on a un nombre variables d'attributs annexes entre les profils. Si tous les utilisateurs ont les mêmes attributs, évite ce modèle qui est plus complexe et moins performant à requêter.
Cependant, si les utilisateurs ne remplissent généralement pas tous les attributs de leur profil, afin d'éviter le peuplement de la table par le bonhomme NULL, c'est une solution qui peut être intéressante.

Oui, de toute façon j'étais parti sur une solution plus simple, avec une relation OneToOne entre mon utilisateur et son profil.

Mais d'après toi, la solution idéale serait davantage de laisser les propriétés de l'utilisateur dans la table utilisateur (plutôt que d'introduire une idée de "profile" fourre-tout pour contenir les champs peu souvent affichées/définis), et de récupérer que ce que l'on souhaite ?

Comme je l'ai dit dans ton autre discussion :
1) On modélise les données rigoureusement ;
2) On implémente le modèle dans la BDD ;
3) On crée les vues nécessaires au programme qui constituent le modèle logique de données, qu'on peut aussi appeler le modèle objet ;
4) Jette l'ORM !
5) Le programme n'utilise que les vues.

1) Ca c'est fait.

3) Pas de vues avec Doctrine, ça n'existe pas .