Как моделировать локализованные предметы - PullRequest
Новая
       20

Как моделировать локализованные предметы

2 голосов
/ 14 апреля 2010

В настоящее время я разрабатываю решение для электронной коммерции. Одним из основных требований для магазина является поддержка локализованных деталей товара. Один и тот же магазин должен поддерживать несколько языков с помощью выбора языка пользователя и / или браузера.

У меня есть две таблицы:
Предмет (id, sku, цена, ...)
ItemDetails (item_id, язык, название, ...)

Для каждого элемента будет несколько строк, соответствующих элементу, где пара (item_id, language) будет уникальной.

Я хотел бы смоделировать это как:
class Item<br> {<br> public string sku;<br> public double price;<br> public ItemDetails Details;<br> }<br>

Исходя из сеанса пользователя, я бы хотел, чтобы возвращаемые элементы имели объект Details, соответствующий выбранному пользователем языку (из их сеанса).

Каковы некоторые подходы для представления этого?

Ответы [ 2 ]

1 голос
/ 08 октября 2010

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

create table Item
(
   ItemID
   ,Sku
   ,Price
   ,Title -- invariant, fallback culture
)


create table Item_Culture
(
   ItemID
   ,CultureCode -- ex: en-US, en-CA, fr-CA, en-UK, fr-FR, en, fr
   ,Title
)

select i.ItemID, i.Sku, i.Price, coalesce(ic.Title, i.Title) as Title
from Item i
left outer join Item_Culture ic
   on ic.ItemID = i.ItemID
   and ic.CultureCode = @CultureCode

Где @CultureCode - это параметр, переданный из вашего приложения, а таблица "Культура" содержит список ваших различных языков / культур для справки или для указания запасных языковых зависимостей.

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

0 голосов
/ 14 апреля 2010

Подумайте, как вы получаете списки объектов

  • они кешируются
  • они отфильтрованы / отсортированы / разбиты на страницы
  • они ищут
  • к ним обращаются другие приложения (отчеты, партнеры)

Ответ определяет, сколько логики перевода может быть в приложении и сколько может быть в базе данных.

В приложении, над которым я сейчас работаю, есть списки объектов, доступ к которым возможен только в приложении. Только 2 свойства переведены, и мне не нужно сортировать по этим свойствам. Я загружаю списки объектов, и каждый объект уже имеет переводы для всех языков, сохраненных в словаре. Приятно думать, что мой кеш имеет только одну запись на ключ.

Думать становится сложнее, если вам нужно искать, фильтровать и сортировать по переведенным свойствам. Я бы попытался иметь логику в базе данных тогда.

...