Discussion :

[Invité]

Bonjour,

Nous cherchons actuellement la meilleure stratégie (au niveau performance) à adopter pour gérer le stockage des traductions d'une application en Java. Prendre en compte les points suivants :
- Il faudrait éviter le maximum de jointures. Une table pourrait contenir toutes les traductions mais il faudrait rajouter de nombreuses jointures coûteuses aux requêtes applicatives.
- On doit pouvoir trier ou faire des recherches sur une traduction. Exemple : tris de la liste des clients sur le type de clients. Le type de client est une chaine internationalisable.
- Nous avons essayé les colonnes XMLTYPE pour gérer les trads mais elles sont couteuses en performance.

Avez-vous d'autres solutions ?

Cordialement

[ojo77]

- Il faudrait éviter le maximum de jointures.

Pourquoi ? Le principe du reationnel c'est d'uiliser des jointures pour éviter d'être redondant et donc être performant ...

Une table pourrait contenir toutes les traductions mais il faudrait rajouter de nombreuses jointures coûteuses aux requêtes applicatives.

Coûteuses en quoi ?

Est-il possible d'avoir une description plus détaillée du problème ?

[Invité]

Sur les applications à haute volumétrie, les jointures deviennent très coûteuses en CPU et temps de réponse. Certaines optimisations consistent à ajouter des colonnes de cache sur certaines tables pour éviter ces jointures. Aussi, plus la requête est complexe et plus Oracle aura du mal à trouver un plan d'exécution optimale. Nous cherchons actuellement à déterminer la meilleure solution à mettre en oeuvre pour gérer une internationalisation.

Il y a plusieurs solutions possibles, on peut prendre un exemple sur une table
T_TYPECLIENT avec une colonne label que tu veux internationaliser.

*Solution 1:
- Tu transformes ta colonne label en une colonne qui va contenir la clé de traduction.
- Tu ajoutes une table de traduction (clé de trad, langue, value) avec en valeur par exemple: "champs1.label", "fr_FR", "Nom");
- Dans tes requêtes, tu fais une jointure sur la clé de trad

*Solution 2:
- Tu prévois par exemple 5 colonnes dans ta table TYPECLIENT : langue_fr, langue_en, langue_ar, etc...
- Tu évites la jointure mais ton appli aura un nombre de langues limitées.

*Solution 3:
- On avait pensé à une colonne TRAD de type XMLTYPE sur la table TYPECLIENT qui contient un doc genre <i18n><lng key="fr">Nom</lng><lng key="en">Name</lng></i18n>
- Tu évites la jointure, tu gères autant de langues que tu veux mais on s'est rendu compte que les colonnes xml étaient consommatrices en CPU.

[ojo77]

Je reste convaincu que la solution 1 reste la plus efficiente avec un partitionnement par clé de traduction (en range) avec une pk (clé de traduction + langue).

Il est possible de varier la solution 3 en utilisant des nested tables.

Pas d'autre idée comme ça à chaud

[mnitu]

Sur les applications à haute volumétrie, les jointures deviennent très coûteuses en CPU et temps de réponse. Certaines optimisations consistent à ajouter des colonnes de cache sur certaines tables pour éviter ces jointures. Aussi, plus la requête est complexe et plus Oracle aura du mal à trouver un plan d'exécution optimale.
...

N'importe quoi! Prouvez-le !
Les bases des données existent pour faire des jointures.
Par contre il est vrai que les applications mal écrite peuvent mettre à genou n’importe quelle version d’Oracle ou autre SGBD.

[Invité]

J'ai pas écrit ce post pour critiquer les jointures mais pour trouver la meilleure solution pour gérer les trads par rapport à vos connaissances/expériences.
Si pour vous, cé de le faire avec une table de traductions + jointures, alors vous m'avez répondu

[Waldar]

Je vais dans le même sens que les précédentes réponses : faites un modèle relationnel propre en suivant une méthodologie type Merise.

Si votre base est volumineuse, une bonne combinaison des partitions et index permettront à vos requêtes de répondre extrêmement vite.
Si votre table à la structure à trois colonnes, faites même une IOT partitionnée.

Je reviens là-dessus :

Certaines optimisations consistent à ajouter des colonnes de cache sur certaines tables pour éviter ces jointures.

Ces optimisations n'en sont pas.
Les développeurs qui "optimisent" ainsi ne s'y connaissent que très peu en SQL, et sont persuadés qu'il s'agit d'une super optimisation, alors qu'au final ce n'est qu'un écran de fumée : on fait faire par un serveur applicatif ce qu'un SGBD fait le mieux : en effet vos jointures seront forcément quelque part dans votre code applicatif, avec des jolies boucles qui s'imbriquent.
Et il reste le problème du refresh du cache.
Et si votre cache dépasse la taille de la RAM du serveur applicatif ça ne va rien optimiser du tout.
Et sûrement bien d'autres problèmes dont les développeurs d'optimisations ne vous parleront qu'après la mise en production.

[Invité]

Quand je parlais colonne de cache, ce n'est pas au niveau applicatif mais toujours au niveau de la BD. C'est par exemple pour accéder à une colonne col1 sur une table D à partir d'une table A et que je dois passer par les tables B et C pour y accéder (via jointures).
Et bien pour éviter çà, on peut faire un modèle un peu moins relationel en dupliquant la donnée col1 dans la table A. Comme çà, pas de jointure à faire mais par contre, on pénalise les mises à jour (2 cols à mettre à jour).

Sinon, j'aime bien l'idée des tables IOT. A tester.

[mnitu]

...
Sinon, j'aime bien l'idée des tables IOT. A tester.

Pourquoi ?

[Invité]

Moins d'IO