Bonjour *,
Je serais curieux d'avoir votre avis sur la question suivante:
J'ai naturellement tendance à stocker les traductions de tous les objets en base mais je suis confronté à une autre "école" qui souhaite utiliser, parfois, les fonctionnalités de leurs outils de dvlp (fichiers "plats" de traduction).
Pour préciser le contexte, je m'occupe du modèle de la base (sous postgresql) et le dev de l'appli est sous-traité. Le backoffice est en anglais uniquement, le front en anglais, français et allemand.
Dans ce genre de base, qui fait une bonne centaine de tables, il y en a pas mal qui n'ont que quelques lignes, par exemple le 'type de contenu' peut être soit 'film' soit 'série'. La table liée des traductions contient donc ici 2 objets * 3 langues = 6 lignes.
(et là je ne vous parle pas du fait "qu'on" me force à prendre des enums, au lieu d'une vraie table!)
Autant je comprends que les libellés "fixes" des formulaires de saisie/filtrage proviennent d'un fichier texte, je ne vois pas ce qui gène de faire une requête en filtrant la langue d'affichage avec le cookie de langue FR/EN/DE… Selon moi, c'est de la donnée => en base.
Vous qui développez en symfony, ruby, django, *js, etc, est-ce un problème de perf ? d'orm malfoutu ? de facturation supplémentaire pour gérer une nouvelle langue ? :-)
# les deux, mon capitaine !
Posté par xulops (site web personnel) . Évalué à 4.
Pour le front office (on ne parle que ce celui-là, puis que le backoffice n'est pas multilingue, mais c'est pareil), faut distinguer le contenu statique du contenu dynamique.
Le contenu statique est créé / ajouté par le développeur au moment où il code le truc. S'il devait faire des aller-retours entre son code et la BDD à chaque fois qu'il doit ajouter un libellé, il va vite péter un câble. Donc la partie statique est presque toujours en fichiers qui n'évoluent pratiquement plus une fois le dev terminé. Sur la façon de stocker en fichier, il y a plusieurs écoles.
Le contenu dynamique, il est créé / ajouté par les utilisateurs du site, ou par des personnes en charge de la rédaction, bref pas par des devs, et ils ne savent bien souvent même pas comment sont stockées les données. Dans la grande majorité des cas, c'est stocké en base, avec un index sur la langue du contenu.
Ce sont surtout des considérations pratiques : vitesse/confort de dev pour le statique, facilité de récupérer directement le contenu dans la bonne langue en dynamique.
Maintenant, une base de données, ce n'est qu'un ensemble de fichiers, dans un format particulier, que va lire un moteur de requêtes.
Le meilleur exemple (le plus simple), c'est un fichier VSAM sur AS/400, le fichier peut contenir plusieurs membres, chaque membre est comme un tableau avec colonnes de largeur prédéterminée, par exemple ID de la colonne 1 à 5, langue de la colonne 6 à 14, titre de la colonne 15 à 89, etc.
A côté de ça, tu as des petits fichiers de définition d'index que le moteur DB2 utilise pour retrouver très rapidement que la ligne avec l'id 34564 est à la 23464 ligne du ficher. Un seek, un read, et c'est fini (je simplifie un peu quand même).
Bref, si tu stockes en fichier, tu as un code pour lire le fichier, en extraire la valeur (souvent un fichier de type cle/valeur). Si tu stockes en base, c'est le moteur qui fait le boulot.
Niveau performance, tant que le contenu statique ne fait pas des Mo, la solution fichier est la meilleure car le fichier est lu une fois et reste en cache tout le temps. Si c'est stocké en base, il est possible que le moteur dégage la table en question du cache si d'autres requêtes bien bourrines bouffe la ram jusqu'au paramètre de cache défini. Du coup, le statique en fichiers gagne sûrement un peu niveau IO.
Pour le dynamique, c'est censé gonfler dans le temps, c'est bien en base.
# Commentaire supprimé
Posté par Anonyme . Évalué à 2.
Ce commentaire a été supprimé par l’équipe de modération.
# est-ce un problème (...) d'orm malfoutu ?
Posté par jemore . Évalué à 1.
Ca existe des ORM bien foutus ? Je n'en ai pratiqué aucun (java, php) qui fasse mieux qu'un bon développeur à l'aise en SQL.
# un bon vieux fichier excel
Posté par fearan . Évalué à 2.
Le pire que j'ai vu :
Dans une feuille de calcul excel!!!
Avec des macros !!!
Sinon ici on a de bêtes fichier clé=valeur et clé valeur
même pas foutu d'avoir le même format entre le coté c++ et le coté java (.properties)
coté c++ on a séparé les fichiers entre les différents modules, ce qui fait que l'on peut avoir des duplications mal venue.
Coté java on a séparé les messages (avec paramètres) des labels.
Et donc on a n fichiers par langue…
Il ne faut pas décorner les boeufs avant d'avoir semé le vent
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.