2012-12-13 2 views
5

대부분의 사람들은 아래 접근법을 사용하고 변환이 필요한 특정 테이블에 대한 변환 테이블을 작성하지만 이는 테이블로드에 영향을 줄 수 있음을 알고 있습니다.테이블 용 언어 변환

CREATE TABLE Product 
(
    Product_id 
    ,ProductTrans_id -- FK 
) 

CREATE TABLE ProductTranslation 
(
    ProductTrans_id 
    ,Product_id 
    ,Name 
    ,Descr 
    ,lang_code 
) 

아래의 접근 방법이 실행 가능합니까? 1 개 이상의 열을 번역해야하는 많은 테이블이 있다고 가정 해보십시오. 다음 테이블에서 모든 번역을 1 개의 테이블에 보관할 수 있습니까? 나는이 테이블이 시간이 지남에 따라 커질 것이라고 생각합니다. 적은 수의 테이블을 가진 것은 자동으로 의미하지 않는다 :

CREATE TABLE translation_entry (
      translation_id  int, 
      language_id   int, 
      table_name   nvarchar(200), 
      table_column_name  nvarchar(200), 
      table_row_id   bigint, 
      translated_text  ntext 
     ) 

    CREATE TABLE translation_language (
      id int, 
      language_code CHAR(2) 
     ) 

그래서 당신은 당신이 테이블의 수에 대한 우려 이유를 모르겠어요 그래서

select 
    product.name 
    ,translation_entry.translated_text 
from product 
inner join translation_entry on product.product_id = translation_entry.table_row_id 
and translation_entry.table_name = 'Product' and translation_entry.table_column_name = 'Name' 
and language_id = 3 
+1

두 번째 방법은 오버 헤드가 많은 것처럼 보이며 단일 제품의 번역 된 열을 가져 오기위한 여러 가지 가져 오기가 필요합니다. 제대로 이해하면 ..? +1 좋은 질문입니다! –

+0

좋은 접근 방식은 처음에 쿼리가 어떻게 보이는지 고려하는 것입니다. 테이블 디자인을 위임합니다. –

+0

두 번째 방법에서는 TableName과 ColumnName을 필터링 한 다음 table_row_id를 통해 링크 할 수 있습니다. 쿼리 속도가 느릴 수도 있습니다. 이 작업을 수행하는 방법을 생각하면 새 테이블이나 열 등에 번역이 필요할 때 스키마 변경이 필요하지 않습니다. – davey

답변

2

같은 텍스트를 가져 두 번째 방법을 것이다 사용 귀하의 데이터베이스는 작고, 효율적이며, 더 잘 설계되었습니다. 특히 테이블의 수를 줄이면 쿼리의 복잡성이 증가하므로 매우주의해야합니다.

어쨌든, 나는 '기본'테이블 당 하나의 변환 테이블로 갈 것입니다. 주된 이유는 두 번째 솔루션이 유연하지 않기 때문입니다. 기본 키가 단일 정수가 아닌 경우 구현 및 사용하기가 극도로 어려워집니다. 또한 번역 쿼리는 더욱 복잡하며 테이블 및 데이터의 크기에 따라 효과적으로 인덱싱하기 어려울 수 있습니다.

Products 테이블에 TranslationID이있는 이유가 명확하지 않습니다. 당신의 도구 모음 및 데이터베이스 구축의 일환으로 직접 기지들에서 번역 테이블을 생성 할 수 있습니다 배포 프로세스에 따라

create table dbo.Products (
    ProductCode char(10) not null primary key, 
    ProductName nvarchar(50) not null, 
    ProductDescription nvarchar(100) not null, 
    -- other columns 
) 

create table dbo.ProductsTranslations (
    ProductCode char(10) not null, 
    LanguageCode char(2) not null, 
    ProductName nvarchar(50) not null, 
    ProductDescription nvarchar(100) not null, 
    -- other translations 
    constraint FK1 foreign key (ProductCode) 
     references dbo.Products (ProductCode), 
    constraint FK2 foreign key (LanguageCode) 
     references dbo.Languages (LanguageCode), 
    constraint PK primary key (ProductCode, LanguageCode) 
) 

: 보통의 관계는 다른 방법으로 주위입니다. 그리고 뷰를 사용하여 기본 테이블의 편리하고 '완전히 번역 된'버전을 제공 할 수 있습니다.

재미있는 질문 중 하나는 Products의 열에 어떤 언어가 사용되며 번역이 필요하지 않은 경우 직접 사용할 수 있는지 여부입니다. 내 제안은 모든 프로덕션 코드가 영어 매개 변수를 전달하고 영어로만 (또는 내부 회사 언어가 무엇이든) 심지어 ProductsTranslations 테이블의 텍스트를 가져와야한다는 것입니다. 그렇게하면 모든 '공식'이름이 동일한 테이블에서 발견되고 기본 테이블의 열이 데이터 모델의 명확성과 완전성 및 개발자 편의성 및 임시 사용에 대한 내부 사용 가능성을 확인할 수 있습니다. 보고서 등.

+0

Pondlife에게 감사드립니다. 저는 언어 테이블을 구현하는 다른 방법을 찾고있었습니다. 당신이 묘사 한 디자인은 최선의 접근법처럼 보입니다. – davey