Multilang catalogue (avec des champs personnalisés) Conception de la structure de la base de données

Question

Bientôt, je vais travailler sur le catalogue (php + mysql) qui aura un support de contenu multilingue. Et maintenant, je considère la meilleure approche pour concevoir la structure de la base de données. En ce moment, je vois 3 façons de manutention multilang:

1) Avoir des tables séparées pour chaque donnée langue spécifique, à savoir schematicly ça va ressembler à ceci:

• Il y aura une table Main_Content_Items, stocker des données de base qui ne peuvent pas être traduites comme ID, creation_date, hits, votes etc. - il n'y en aura qu'une et fera référence à toutes les langues.

Et voici les tableaux qui seront dublicated pour chaque langue:

• tableau Common_Data_LANG (exemple: common_data_en_us) (stockage commun/champs « statiques » qui peuvent être traduits, mais sont présents pour eny catalogue item: title, desc et ainsi de suite ...)
• Table Extra_Fields_Data_LANG (en stockant des champs supplémentaires qui peuvent être traduits, mais qui peuvent être différents pour des groupes d'items personnalisés, comme: | id | item_id | field_type | valeur | ...) Ensuite, sur la demande d'éléments, nous allons regarder dans la table en fonction de l'utilisateur/langue par défaut et joindre des données traduisibles avec main_content table.

Plus:

• nous pouvons mettre à jour les données « principales » (c.-à-coups, voix ...) qui sont mis à jour le plus souvent avec une seule requête
• on n'a pas besoin o données doublon 4x ou plus si nous avons 4 langues ou plus en comparaison avec la structure en utilisant seulement une table avec le champ 'lang'. Alors requêtes Mysql prendrait moins de temps pour passer par 100000 (par exemple) enregistre catalogue plutôt que 400000 ou plus

Moins:

• tables pour chaque langue

2) Utilisation du champ 'lang' dans les tables de contenu:

• Table Main_Content_Items (stockage de données de base qui ne peut pas être traduit comme ID, creation_date, frappe, vote ainsi de suite ...)
• Common_Data Table (stockage commun/champs « statiques » qui peuvent être traduits, mais sont présents pour eny item du catalogue: | id | item_id | lang | titre | desc | et ainsi de suite ...)
• Table Extra_Fields_Data (en stockant des données de champs supplémentaires qui peuvent être traduites, mais qui peuvent être différentes pour les groupes d'éléments personnalisés, par exemple: | id | item_id | lang | field_type | value | ... Nous allons donc joindre common_data et extra_fields à main_content_items en fonction du champ 'lang'.

Plus:

• nous pouvons mettre à jour "principaux" données (visites, votes ...) qui sont mis à jour le plus souvent avec une seule requête
• nous seulement 3 tables pour les données de contenu

Moins:

• nous avons table custom_data et extra_fields esprit rempli h données pour toutes les langues, de sorte que son temps de X plus gros et les requêtes fonctionnent plus lentement

3) Identique au mode 2, mais avec table Main_Content_Items fusionné avec Common_Data, qui a le champ « lang »:

Plus:

• ...?

Moins:

• nous avons besoin de mettre à jour la mise à jour "principales" données (visites, votes ...) qui sont mis à jour le plus souvent avec pour toutes les langues
• nous avons table custom_data et extra_fields rempli avec des données pour toutes les langues, de sorte que son temps X plus grand et les requêtes tournent plus lentement

Sera heureux d'entendre des suggestions sur "quoi de mieux" et "pourquoi"? Ou y a-t-il de meilleurs moyens?

Merci à l'avance ...

Answer 1

J'ai donné une anwer similaire dans this question et a souligné les avantages de cette technique (il serait, par exemple, important pour moi de laisser l'application décider de la langue et construire la requête en conséquence en changeant seulement le paramètre lang dans la clause WHERE de la requête SQL.

Ce get est assez proche de votre deuxième solution. Je n'ai pas tout à fait obtenu les « extra_fields » mais s'il est logique, vous could (!) le fusionner dans la table common_data Je vous déconseille la première idée depuis Mal être trop de tables et il peut être facile de perdre la trace des articles là-bas. Pour votre édition: je considère toujours la deuxième approche la meilleure (c'est mon optinion donc c'est relatif;)) Je ne suis pas expert en optimisation mais je pense qu'avec des index appropriés et une bonne structure de table, la vitesse ne devrait pas être un problème. Comme toujours, la meilleure façon de trouver le moyen le plus efficace est de faire les deux méthodes et voir ce qui est le mieux puisque la vitesse variera des données, la structure, ....