Quel modèle est le meilleur?

Question

Nous utilisons maintenant Django pour développer un site web multilingue. Nous avons une version linguistique différente pour le contenu sur notre site Web. Par exemple, pour un post, nous avons la version anglaise et espagnole. Actuellement nous utilisons ce modèle:

class Post(models.Model): 
    user 
    title 
    detail 
    count_follower 
    ... 
    orginal_language 
    date 


class PostEspanish(models.Model): 
    post = models.ForeignKey(Post) 
    title 
    detail 

Nous utilisons Postes pour tous les contenus en anglais et PostEspanish pour le contenu espagnol. Si quelqu'un écrit un article en anglais, nous le mettons simplement dans un modèle Post, et nous mettons un post traduit dans un modèle PostEspanish. Et si quelqu'un écrit un post en espagnol, nous créons d'abord une instance Post, puis créons une instance PostEspanish et mettons du contenu dans PostEspanish, et si quelqu'un traduit cet article en espagnol, nous mettons un post traduit dans son Post de référence.

Le stockage de contenu linguistique différent sur un modèle différent est dû au fait que le chercheur le souhaite de cette façon. Il dit que c'est bon pour la recherche.

Pour le rendre plus clair, par exemple, certains utilisateur écrit un message, nous allons effectuer les opérations suivantes:

if language == 'English': 
    post = Post.objects.create(..., orginal_language='english') 
else: 
    post = Post.objects.create(..., original_language='espanish') 
    PostEspanish.objects.create(post=post, ...) 

et TRADUIT:

post = Post.objects.get(id=id) 
if post.orginal_language == 'english': 
    post = post.postespanish 
    #update post 
    post.save() 
else: 
    #update post 
    post.save() 

quelqu'un a dit aujourd'hui cette conception de modèle est vraiment mauvaise . Il a dit que le modèle actuel n'est pas bien orienté objet. Voici la façon dont ils le font:

class Post(models.Model): 
    user 
    count_follower 
    ... 
    orginal_language 
    date 

class PostContentEnglish(models.Model): 
    post = models.ForeignKey(Post) 
    title 
    detail 

class PostContentEspanish(models.Model): 
    post = models.ForeignKey(Post) 
    title 
    detail 

Ainsi, le code sera comme ceci:

if language == 'English': 
    post = Post.objects.create(..., orginal_language='english') 
    PostContentEnglish.objects.create(post=post,...) 
else: 
    post = Post.objects.create(..., orginal_language='espanish') 
    PostContentEspanish.objects.create(post=post,...) 

Mais la plupart d'entre nous pensaient qu'il n'y a pas de différence entre ces deux approches. Et la conception de son modèle va générer une table de plus, ce qui est vraiment mauvais.

Alors, à votre avis, quel est le meilleur?

Answer 1

En règle générale, les langues sont enregistrées comme (pseudo-code):

posts (
    id  serial pkey, 
    pubdate datetime 
) 

posts_lang (
    id  int fkey posts (id), 
    lang  char(2), 
    title varchar, 
    content text, 
    pkey (id, lang) 
) 

Une autre approche que je l'ai vu plusieurs fois, est la suivante:

posts (
    id  serial pkey, 
    parent int fkey posts (id), 
    lang  char(2), 
    pubdate datetime 
    title varchar, 
    content text 
) 

Son avantage est qu'il permet de gérer les attributs spécifiques aux paramètres régionaux (balises anglaises/meta vs balises espagnoles/meta, par exemple). Mais il se transforme rapidement en un cauchemar de manipulation des arbres. Donc pas recommandé.

Et, bien sûr, il y a celui que vous utilisez, avec la langue par défaut directement dans le tableau:

posts (
    id  serial pkey, 
    pubdate datetime 
    title varchar, 
    content text, 
) 

posts_lang (
    id  int fkey posts (id), 
    lang  char(2), 
    title varchar, 
    content text, 
    pkey (id, lang) 
) 

je peux voir le rationnel de vouloir la langue par défaut directement dans la table. Mais dans mon expérience, il introduit la duplication de code - c'est-à-dire que vous faites constamment deux choses - et donc des bugs/bizarreries. Donc, ne peut pas vraiment recommandé non plus.

Mon alternative préférée est aucune de ces - et en utilisant un schéma différent (ou DB ou préfixe de table) pour chaque langue:

en.posts (
    id  serial pkey, 
    pubdate datetime 
    title varchar, 
    content text 
) 

es.posts (
    id  serial pkey, 
    pubdate datetime 
    title varchar, 
    content text 
) 

La raison pour laquelle je préfère est qu'il est fréquent pour un site avoir des pages non traduites et autres, ou des pages qui existent sur un site mais pas sur l'autre. Et le plus souvent votre contenu ne devrait pas être identique d'un pays à l'autre - vous ne communiquez pas à votre public de la même manière.

Answer 2

Le modèle qu'il propose semble plus sensé; traiter les langues La même chose a plus de sens pour moi que de les traiter différemment, et il est plus approprié de les normaliser.

Toutefois, plutôt que de créer une table pour chaque langue, créez une table pour le contenu et ajoutez une colonne pour indiquer la langue.