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.
# les deux, mon capitaine !
Posté par xulops (site web personnel) . En réponse au message Stockage de traductions en bdd v/s application. É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.