Локализация данных в SQL Server с GUID или ...? - PullRequest
Новая
       18

Локализация данных в SQL Server с GUID или ...?

7 голосов
/ 04 марта 2010

Мне нужно сделать базу данных сильно локализованной. Почти для всех организаций мне нужен перевод на 5+ языков. Некоторым объектам даже требуется и локализованный дополнительный ресурс (например, изображения, которые я ввожу как пути).

Вопрос теперь:

1: СМОТРЕТЬ СТОЛ НА ЕДИНСТВО / ТАБЛИЦУ (вроде раздутая схема?)

я должен создать "Локализованную" таблицу поиска локализации для каждой таблицы, в которой мне нужны локализованные значения (и использовать стандартные PK int / bigint для элементов) Как здесь: 

MYITEMS
-------
 - MyItemId BIGINT PK
 - MyItemPrice DECIMAL

MYITEMLOCALIZED
---------------
 - CPK_MyItemId BIGINT FK
 - CPK_LanguageCode NCHAR
 - LocalizedName NVARCHAR
 - LocalizedResourcePath NVARCHAR

CUSTOMERS
---------
 - CustomerId BIGINT PK
 - CustomerName NVARCHAR

CUSTOMERLOCALIZED
---------------
 - CPK_CustomerId BIGINT FK
 - CPK_LanguageCode NCHAR
 - LocalizedName NVARCHAR
 - LocalizedResourcePath NVARCHAR

или

2: НАПРАВЛЯЮЩИЕ С СТОЛОМ ЛОКАЛИЗАЦИИ ОДИНОЧНОГО ВЗГЛЯДА (интенсивное использование направляющих?)

я должен использовать GUID в качестве PK, а затем просто использовать одно имя и одну таблицу локализации ресурса. 

MYITEMS
-------
 - MyItemId uniqueidentifier PK
 - MyItemPrice DECIMAL    

CUSTOMERS
---------
 - CustomerId uniqueidentifier PK
 - CustomerName NVARCHAR

LOCALIZED
    ---------------
     - CPK_ElementGuid uniqueidentifier FK
     - CPK_LanguageCode NCHAR
     - LocalizedValue NVARCHAR
     - LocalizedResourcePath NVARCHAR

3: ОДИНОЧНЫЙ ВЗГЛЯД, НО НАПРАВЛЯЕТСЯ ТОЛЬКО ДЛЯ ЛОКАЛИЗАЦИИ (лучшее из двух миров?)

я должен использовать обычные PK int / bigint, а затем добавить столбец GUID для каждого нужного мне столбца и сохранить локализованные значения в одной таблице поиска локализации. 

MYITEMS
-------
 - MyItemId BIGINT PK
 - MyItemPrice DECIMAL
 - ItemNameLocalizationGuid uniqueidentifier(GUID)
 - ItemPictureLocalizationGuid uniqueidentifier(GUID)


CUSTOMERS
---------
 - CustomerId BIGINT PK
 - CustomerName NVARCHAR
 - CustomeerNameLocalizationGuid uniqueidentifier(GUID)

LOCALIZED
---------------
 - CPK_ElementGuid uniqueidentifier FK
 - CPK_LanguageCode NCHAR
 - LocalizedValue NVARCHAR

4: ПОСМОТРЕТЬ СТОЛ, КОТОРЫЙ ВОЗВРАЩАЕТСЯ ID ЛОКАЛИЗАЦИИ (переходить назад и вперед?)

я должен создавать таблицы без направляющих, но хранить идентификатор локализации в материнской таблице?

Как здесь: 

MYITEMS
-------
 - MyItemId BIGINT PK
 - MyItemPrice DECIMAL
 - MyItemNameLocalizedId BIGINT    

CUSTOMERS
---------
 - CustomerId BIGINT PK
 - CustomerName NVARCHAR
 - CustomerGenderLocalizedId BIGINT

LOCALIZED
---------------
 - LocalizationId BIGINT PK
 - CustomerId BIGINT FK
 - LanguageCode NCHAR
 - LocalizedName NVARCHAR
 - LocalizedResourcePath NVARCHAR

Если я использую идентификаторы GUID в качестве прочитанных мной PK, я понесу огромные потери производительности и размера данных, но я также сразу же столкнусь с уникальностью элементов на серверах, dbs ...

1 Ответ

12 голосов
/ 04 марта 2010

Прежде всего, я настоятельно рекомендую использовать существующий стандарт для идентификаторов локализации - не изобретайте еще одну систему! Используйте стандартные коды ISO-639 для языка, например, «en» для английского, «fr» для французского и т. д.

См. Википедия для получения списка всех определенных кодов.

Во-вторых, исходя из своего опыта и суждений, я бы использовал таблицу языков для каждой сущности.

У нас обычно есть «системное имя» в главной таблице, например, текст на английском языке, а затем у нас есть таблица "(entity) _TX" для текстового представления на разных языках.

Примерно так: 

  TABLE CustomerType
      CustomerTypeID    INT IDENTITY(1,1) PK
      CustomerTypeName  VARCHAR(100)    -- English "system" name, e.g. "Gold customer"

  TABLE CustomerType_TX
      CustomerTypeID    INT
      LanguageID        CHAR(2)   -- ISO-639 codes
      CustomerTypeText  VARCHAR(200)   -- translated texts

Для меня это более понятно, более явно и более "интуитивно", чем использование единой схемы кодирования на основе GUID.

...