2011-08-23 1 views
1

J'écris un plugin de localisation pour mes cms. J'ai quelques options pour le faire mais le plus simple est de créer des colonnes supplémentaires pour chaque langue (comme title_en, content_en).lequel est le meilleur pour les performances de mon projet, plus de colonnes ou plus de lignes?

L'autre façon est de créer une colonne appelée «langue» et chaque langue dans chaque article, je crée une ligne. Cependant les zones dynamiques ne sont que 'title', 'content' et 'nice_url' mais il y a 10 colonnes (id, catégorie, affichage, date ...) et ces colonnes seront inutiles.

Les autres méthodes (comme créer une table supplémentaire nommée article_translations) ne sont pas adaptées à l'algorithme de plugin de mon CMS.

Répondre

2

Plus de colonnes ne sont pas évolutives, et il est beaucoup plus facile d'ajouter des lignes que des colonnes.

Il est préférable d'avoir une ligne pour les données de chaque langue.

Vous n'avez pas publié beaucoup d'informations, mais essayez de mettre toutes les données communes dans une table unique et de mettre les données spécifiques à la langue dans une autre table enfant avec une clé étrangère ou un type enum pour la langue. Utilisez une clé étrangère dans une table de langues s'il existe des informations sur la langue à stocker/récupérer. Utilisez une énumération à la place si vous voulez vérifier la valeur, ou utilisez simplement du texte si vous n'êtes pas difficile.

En outre, il convient de noter qu'il est peu probable que vous vouliez plus d'une langue à la fois, il n'y a donc aucun avantage à avoir une table extrêmement large où une ligne contient toutes les informations sur toutes les langues.

+0

En fait, il est facile d'implémenter mon projet, car si j'utilise "plus de lignes", je dois créer une colonne supplémentaire appelée owner_article et je dois vérifier et mettre à jour ces lignes chaque fois (supprimer, mettre à jour et éditer) –

+1

Postez quelques informations supplémentaires sur les données que vous devez stocker. Nous pouvons mieux vous aider si nous en savons plus sur ce que vous essayez de faire. – Bohemian

+0

Il y aura des articles et chaque article sera dans quelques langues. Les fonctionnalités d'un article seront utilisées dans toutes les traductions. Si on implémentait cette fonctionnalité sur mes cms, ça pourrait être facile mais ce sera un plugin et si j'utilise "plus de lignes" je dois changer beaucoup de choses dans la façon de créer des plugins, parce que ça ne convient pas pour le plugin fonctionnalité. –

0

La solution dépend du nombre de langues que vous envisagez de prendre en charge? Si plusieurs vous pouvez ajouter plusieurs colonnes supplémentaires sans aucun problème. Il sera facile d'utiliser ce modèle pour passer d'une langue à l'autre. Mais si vous prévoyez utiliser plusieurs langues, je pense que vous devriez penser à des tables supplémentaires.

+0

Un utilisateur utilise généralement 4-5 langues et cela signifie un total de 15 colonnes (titre, contenu, nice_url). ça fait un problème? –

+0

Mieux vaut avoir une sous-table qui stocke des traductions de langue spécifiques, alors. Alors vous avez seulement autant d'enregistrements que de traductions, et vous ne vous retrouvez pas avec une table pleine d'enregistrements null/default où il n'y a pas de traduction disponible. –

+0

Non, ce ne sera pas un problème si vous n'avez pas besoin de chercher par cette table. Parce que la table sera énorme, vous obtiendrez de gros index et même pour la clé primaire si vous utilisez InnoDB –

Questions connexes