Où fixez-vous vos limites avec POO ? Dénormalisation.

[dorian53]

Bonjour,

Etes-vous plutôt full POO ou adepte de la dénormalisation ? Et comment ?

Prenons le cas de la gestion d'un utilisateur, vous allez certainement gérer une classe User (liée à votre table en bdd).

User
- id
- nom
- prenom
- sexe_id
...

Pour l'exemple, je souhaite m'attarder sur l'attribut sexe_id.
Au niveau d'une conception SGBDR, le sexe_id correspond à une clé étrangère.

1/ Allez-vous créer cette table sexe avec seulement deux valeurs ?
2/ Allez-vous créer cette classe sexe ?
3/ Comment allez-vous créer la méthode findAll de votre DAO Sexe ?
- Va-t-il se connecter à un SGDBR
- Va-t-il retourner deux entités Sexe ou un tableau en dur
...

Sexe
- id
- nom

DAO_Sexe
- findAll()

Cet attribut est un exemple parmi tant d'autres.

Merci pour vos retours.

 

[spout]

1) Non, c'est juste M ou F, je vois pas trop l'intérêt.
2) Non plus.
3) Vu que je crée pas de modèle spécifique (Sex). Pour la traduc ou autres besoins, je le défini tt simplement comme ceci:

<span class="syntaxdefault"><br />$sex&nbsp;</span><span class="syntaxkeyword">=&nbsp;array(</span><span class="syntaxstring">'M'&nbsp;</span><span class="syntaxkeyword">=>&nbsp;</span><span class="syntaxdefault">__</span><span class="syntaxkeyword">(</span><span class="syntaxstring">'Homme'</span><span class="syntaxkeyword">),&nbsp;</span><span class="syntaxstring">'F'&nbsp;</span><span class="syntaxkeyword">=>&nbsp;</span><span class="syntaxdefault">__</span><span class="syntaxkeyword">(</span><span class="syntaxstring">'Femme'</span><span class="syntaxkeyword">));<br />&nbsp;</span><span class="syntaxdefault"></span>

Et pour les find:

<span class="syntaxdefault"><br />$femaleUsers&nbsp;</span><span class="syntaxkeyword">=&nbsp;</span><span class="syntaxdefault">$this</span><span class="syntaxkeyword">-></span><span class="syntaxdefault">User</span><span class="syntaxkeyword">-></span><span class="syntaxdefault">findAllBySex</span><span class="syntaxkeyword">(</span><span class="syntaxstring">'F'</span><span class="syntaxkeyword">);<br /></span><span class="syntaxdefault">$maleUsers&nbsp;</span><span class="syntaxkeyword">=&nbsp;</span><span class="syntaxdefault">$this</span><span class="syntaxkeyword">-></span><span class="syntaxdefault">User</span><span class="syntaxkeyword">-></span><span class="syntaxdefault">findAllBySex</span><span class="syntaxkeyword">(</span><span class="syntaxstring">'M'</span><span class="syntaxkeyword">);<br />&nbsp;</span><span class="syntaxdefault"></span>

(Sachant que j'utilise CakePHP)

 

[chtipepere]

Bonsoir,

Cet attribut est un exemple parmi tant d'autres.

Malheureusement, le "genre" d'un utilisateur est un cas particulier.
Il n'y a aucun intérêt à utiliser une clé étrangère, un enum suffira largement.

Par contre, pour une valeur du type : "ville de naissance", "avatar par défaut", tu pourrais avoir besoin d'une clé étrangère provenant d'une table secondaire.
Tu pourrais accéder à ces valeurs via un ORM en utilisant ce genre de code :

echo UsrTable::getInstance()->getCity()->getName();

getCity étant un accesseur à la table city, qui possède un champ name.

Si tu utilises un ORM, les classes nécessaires seront générées automatiquement (avec doctrine par exemple), les accesseurs et les "setteurs" existeront aussi automatiquement (très proche de la syntaxe cake PHP du dessus).

 

[dorian53]

Merci pour vos réponses.

OK pour l'ORM chtipepere, tout ça est parfaitement clair, c'est justement contre cette lourdeur d'implémentation que j'essaie de débattre. Jusqu'où faut-elle la suivre ? Et si on ne la suit pas comment gérer cette désorganisation ?

Nous sommes d'accord que cette table sexe ne sert à rien :
- faut-il virtualiser la classe coté code (avec un objet à deux attributs tout aussi inutile),
- faut-il dériver sur du code à plat (avec un tableau comme spout)...

Je suis aussi sensible aux conventions qu'à l'optimisation des performances, d'où mon dilemme.