Какая модель дизайна лучше? - PullRequest
0 голосов
/ 11 июня 2011

Мы сейчас используем Django для разработки многоязычного веб-сайта. У нас есть разные языковые версии для контента на нашем сайте. Например, для поста у нас есть английская и испанская версии. В настоящее время мы используем эту модель:

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


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

Поэтому мы используем Post для всего английского контента и PostEspanish для испанского контента. Если кто-то пишет сообщение на английском, мы просто помещаем его в модель Post, а переводим сообщение в модель PostEspanish. И если кто-то пишет сообщение на испанском языке, мы сначала создаем экземпляр Post, затем создаем экземпляр PostEspanish и помещаем контент в PostEspanish, а если кто-то переводит этот испанский текст, мы помещаем переведенный пост в его ссылающийся пост.

Хранение контента на разных языках на разных моделях происходит потому, что поисковик хочет именно так. Он говорит, что это хорошо для поиска.

Чтобы было понятнее, например, какой-то пользователь пишет сообщение, мы сделаем следующее:

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

и переводит:

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

Сегодня кто-то сказал, что дизайн этой модели действительно плохой. Он сказал, что текущая модель не очень хорошо ориентирована на объект. Вот как они это делают:

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

Итак, код будет таким:

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,...)

Но большинство из нас думали, что между этими двумя подходами нет никакой разницы. И его дизайн модели создаст еще одну таблицу, которая действительно плоха.

Так какой из них вы считаете лучше?

Ответы [ 2 ]

2 голосов
/ 11 июня 2011

Модель, которую он предлагает, кажется более разумной; отношение к языкам То же самое имеет для меня больше смысла, чем отношение к ним по-другому, и оно более уместно нормализовано.

Однако вместо создания таблицы для каждого языка создайте одну таблицу для содержимого и добавьте столбец для указания языка.

0 голосов
/ 11 июня 2011

Обычно языки хранятся следующим образом (псевдокод):

posts (
  id       serial pkey,
  pubdate  datetime
)

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

Альтернативный подход, который я видел несколько раз, таков:

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

Его преимущество в том, что он позволяет работать со специфичными для локали атрибутами (например, английские теги / мета против испанских тегов / мета). Но это быстро превращается в кошмар обработки деревьев. Так что не рекомендуется.

И, конечно, есть тот, который вы используете, с языком по умолчанию прямо в таблице:

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)
)

Я вижу рациональное требование языка по умолчанию прямо в таблицу. Но по моему опыту, это приводит к дублированию кода - то есть вы постоянно делаете вещи двумя способами - и, таким образом, ошибки / причуды. Так что на самом деле не могу рекомендовать.

Моя предпочтительная альтернатива - ничего из вышеперечисленного, и для каждого языка используется отдельная схема (или БД, или префикс таблицы):

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

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

Причина, по которой я предпочитаю, состоит в том, что у сайта часто есть непереведенные страницы и тому подобное, или страницы, которые существуют на одном сайте, но не на другом. И чаще всего ваш контент не должен совпадать с из одной страны в другую - в любом случае, вы не общаетесь со своей аудиторией одинаково.

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...