Хранение данных i18n в базе данных с использованием XML

Question

Возможно, мне придется хранить некоторые i18n-ed данные в моей базе данных, используя XML, если я не буду сопротивляться. Это не мой выбор, но это в спецификациях, которым я должен следовать. Например, в столбце «Страна» должно быть что-то вроде следующего:

<lang='fr'>Etats-Unis</lang>
<lang='en'>United States</lang>

Это относится ко многим столбцам в базе данных.

Я не думаю, что это хорошая идея. Я склонен думать, что ячейка в базе данных должна представлять один фрагмент данных (лучше для поиска), и что база данных должна иметь максимум два измерения, а не 3 или более (для каждого измерения потребуется один запрос больше измерение здесь будет равно количеству атрибутов XML).

Моя идея заключалась в том, чтобы иметь отдельную таблицу для всех переводов с такими столбцами, как: ID / Язык / Перевод. Тем не менее, я должен признать, что я действительно не уверен, как лучше всего хранить данные на разных языках в БД ...

Спасибо за советы:)

Answer 1

Согласитесь со своим видением мышления.

В предыдущем проекте мы делали то же самое (сохраняли значения I18N в БД), в дополнение к традиционному I18N (файлы ресурсов в решении).

Причиной этого были специальные динамические данные (не статические строки), которые требовали перевода. У нас были спортивные состязания - такие как "Футбол", который нужно было перевести на их описание для конкретного языка.

Для этого у нас была простая справочная таблица с колонками (LCID - int, SportID - int, Description - nvarchar(256)).

Хранимые процедуры / функции принимали языковой стандарт как целое число (например, испанский - 3082), тогда SQL возвращал бы соответствующее чувствительное к культуре описание на основе языкового стандарта. Таким образом, код веб-сервера не знал об этом за кулисами.

Таким образом, у вас могут быть следующие несколько строк:

Lcid       SportID      Description
3081       1            Soccer
3082       1            Futbol

Затем вы просто присоединяетесь к этой таблице в своем SQL, чтобы упростить I18N.

Небольшой недостаток этого метода заключается в том, что вашему SQL SP нужно запрашивать LCID в качестве параметра из кода веб-сервера.

Спорт были обновлены / импортированы с помощью массового импорта листов Excel, поэтому нам понадобился I18N в БД.

Это единственный способ, которым я могу представить возникновение основанного на БД I18N.

Answer 2

Хотя XML, возможно, не лучший тип для его хранения - хотя, в зависимости от поддержки СУБД, он может быть не таким плохим для производительности, как кажется на первый взгляд - концепция перевода как тип данных, а не нормализация, имеет проблему некоторая заслуга.

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

По сути, если вы думаете о переведенных строках как о «представлении» одного «факта», то нормализация перестает быть подходящим инструментом для работы. Вместо этого вы можете рассматривать «переведенную строку» как атомарный тип с операциями для получения правильного (или лучшего из доступных) перевода, добавления нового перевода и т. Д.

С философской точки зрения, понятие "атомное" сложно. В своем блоге я говорю о том, является ли одна строка «атомарной» - ее можно разделить на отдельные символы, и вы можете даже захотеть узнать, что такое первый символ, но с точки зрения область, которую вы моделируете, обычно считается представительной деталью, а вся строка представляет собой атом. Менее экстремально, PostgreSQL включает тип «точка», который в основном представляет собой просто массив из двух чисел, но допускает непосредственное выражение таких операций, как «содержит» и «выше».