Lier la valeur d'un champ en base de données à sa valeur affichable

Bonjour,

J'ai classé ce sujet en PHP, mais en fait je pense que c'est une problématique qu'on peut retrouver dans plusieurs langages.

J'ai un modèle dans lequel j'ai un champ qui peut contenir une liste de valeurs prédéfinies (mettons des noms de cursus post-bac). En base de données ce champ est un smallint (la liste n'est pas très longue).

Ensuite, pour lier les valeurs numériques de la base de données à leur version affichable, j'utilise un hash statique ainsi qu'un accesseur.

Ça donne un truc de ce style (sous Symfony) :

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28

<?php
/**
* @var integer
*
* @ORM\Column(name="section", type="smallint", nullable=true)
* @Assert\Range(min="1", max="4", minMessage="Choisissez une valeur valide.",
*      maxMessage="Choisissez une valeur valide.")
*/
private $section;

/**
* @var array
*/
private static $sectionName = array(
     '1' => 'Classe préparatoire',
     '2' => 'IUT',
     '3' => 'BTS',
     '4' => 'Université'
);

/**
* Get sectionName
* @return array
*/
public static getSectionName ()
{
     return self::$sectionName;
}

L'avantage de cette technique, c'est que je peux l'utiliser assez simplement depuis Twig avec une syntaxe du type {{ user.sectionName[user.section] }}.

Cette manière de faire me convient, le truc c'est que je l'ai « trouvée » par moi-même et un peu par hasard, c'est pour cela que je me demande s'il n'existe pas plutôt une bonne pratique qui pourrait répondre à ce type de problématique et qui serait peut-être plus élégante que ce que je fais actuellement.

Merci pour vos réponse !

Bonjour,

Je trouve que ta solution est valable. Mais personnellement j'aurai plutôt créé une nouvelle classe Section. J'aurai par la suite fais une relation ManyToOne pour directement faire en twig : {{ user.section.name }}, ou en PHP $user->getSection()->getName().

L'avantage de cette méthode est qu'il est plus facile de rajouter par la suite des nouvelles sections. Il suffit de faire une page contenant un simple formulaire pour ajouter des sections dans la base de donnée. Le désavantage serait que cela rallonge la requête SQL :/

Si quelqu'un a une meilleur idée je serai ravi d'en apprendre plus

Un ENUM ne convient pas ? Si les données ne sont pas vouées à évoluer bien sûr.

Mixer les données avec le code comme ce que tu fais est rarement une bonne idée.

Salut !

Je plussoie l'idée de la relation. Mais si tu n'en veux pas, tu peux te créer ton propre type de formulaire, enfant du type 'choice', dans lequel tu pourras mettre les sections que tu souhaites.

Merci à tous pour vos réponses.

yata > C'est pas mal l'idée de la relation mais le truc c'est que l'entité serait vraiment très très peu amenée à changer. L'exemple que j'ai donné est pas forcément pertinent - c'est le premier qui m'a traversé l'esprit sachant que les données réelles sont de nature un peu plus confidentielle -, mais pour donner une idée il n'y aurait aucun rajout ou suppression et peut-être une modification tous les cinq ou dix ans. C'est pour ça que créer une entité et une table dans ma base de données - déjà bien garnie -, ça me paraît un peu lourd juste pour ça.

yoch > J'ai conscience que ma manière de faire, même si elle fonctionne, est loin d'être parfaite… C'est vrai que j'ai toujours été relativement réticent à mettre des données directement dans le code, mais dans le cas qui m'occupe je considérais plus ça comme des constantes liées au projet que comme des données par conséquent le fait de les fixer dans le code me gênait un peu moins. Concernant ENUM, je ne connaissais pas. Le truc c'est que ça m'ennuie un peu de créer une table dans ma base de données et donc d'alourdir le stockage et le chargement juste pour des constantes de langue qui risquent de changer une fois tous les 10 ans. Après si c'est la seule manière de faire ça « proprement », je m'y résoudrai.

Ymox > À moins que je ne fasse erreur, le problème d'une telle solution c'est que je pourrais pas l'utiliser dans une vue qui ne possède par ledit formulaire. Pour reprendre l'exemple que j'ai donné, j'ai bien sûr un formulaire permettant de choisir le type d'étude que poursuit l'utilisateur de mon entité, mais dans une vue qui ne ferait que l'affichage des données sans possibilité d'agir dessus (donc pas de formulaire), je ne pourrais pas accéder à ce type. L'un des avantages de ma manière de faire c'est que même depuis les formulaires je peux accéder assez facilement aux valeurs que j'ai définies en mettant User::getSectionName() associé à la clé choices des paramètres liés à mon champ choice.

Ymox > Parce que jusque là je pensais que la seule solution était de stocker la chaîne à afficher dans la base de données. Or derrière j'ai aussi besoin de cette valeur pour faire des tests, du coup c'est un peu moins pratique sur une chaîne de caractères que sur un entier. Maintenant, avec ce que viens de m'expliquer yoch, il semblerait qu'avec ENUM ce soit une bonne solution, donc effectivement je vais adopter cette façon de faire, merci à toi ! Quant au composant translation, sachant que le site ne sera pas multilingue, ça me paraît un peu lourd juste pour ce problème.

yoch > Ah d'accord, au temps pour moi. Du coup, bien que l'implémentation d'ENUM sur Doctrine nécessite visiblement un peu de bidouillage, je vais m'orienter vers cette solution. Merci pour tes explications !

Remarque si ton orm rend les choses compliquées avec un enum, ça ne vaut peut-être pas le coup.

Dans ce cas tu me conseillerais quelle solution ?