Comment mappez-vous les étiquettes GUI aux champs de base de données?

Question

Pour les interfaces graphiques qui affichent de nombreux champs de base de données, il est souhaitable d'avoir un champ: étiquette de libellé afin que les étiquettes de l'interface graphique ne soient pas codées en dur, mais définies dynamiquement. Par exemple

• hauteur: "Hauteur (cm)"
• âge: "Âge en années"
• bloodAlcPct: "Blood Alcohol%"
• monthsIncarcerated: "mois en prison"

Où stockez-vous ces chaînes et comment sont-elles mappées aux champs de base de données? Vous pouvez supposer que les utilisateurs demandent des changements fréquents à ces étiquettes.

Answer 1

Vous pouvez utiliser une table méta contenant des informations sur les champs de la table. Vous trouverez toujours plus d'utilisations pour cette table une fois que vous l'avez.

Answer 2

Je ne stocker ces données dans votre base de données, mais plutôt les ai cartographié dans votre modèle OO qui représente la table de base de données comme cela se fait dans toutes les bonnes ORM (regarder django, kohana-ORM, activerecord etc.)

EDIT:

Bien ... cela dépend de ce que vous appelez codé en dur. Le codage dur se réfère généralement à quand vous l'avez dans le code chaque fois que vous utilisez le champ dans un formulaire ou une sortie. Dans la classe ORM, elle est définie une seule fois et réutilisée à partir de ce moment. Vous pouvez également utiliser la méthode _get si vous souhaitez utiliser des langues différentes.

Vous devez définir l'étiquette à un endroit. Je trouve que cela crée trop de frais généraux si vous mettez dans la base de données puisque vous devez récupérer les informations de la base de données. Selon le type d'interface graphique que vous utilisez peut-être beaucoup de fois. En fin de compte, vous avez deux choses à équilibrer: performance, lisibilité et extensibilité du code. L'encapsuler dans une classe le rend propre à partir des deux perspectives, sauf dans le cas où l'étiquette est modifiée par les utilisateurs, alors ce sont des données dynamiques et devraient être dans la base de données.

Quoi qu'il en soit, c'est souvent une question de situation particulière et de goût personnel. Par conséquent, il n'y a pas de bonne ou de mauvaise solution ici.