2009-08-24 2 views
8

namedescription 개의 열을 포함하는 데이터베이스 테이블을 현지화해야합니다.데이터베이스 현지화

product 
------- 
id 
name 
description 


local_product 
------- 
id 
product_id 
local_name 
local_description 
locale_id 


locale 
------ 
id 
locale 

그러나,이 솔루션은 localization을 필요로 name 및 설명 열을 포함하는 모든 테이블에 대한 새로운 local_ 테이블이 필요 :이 기능을 지원 것 DB 스키마를 설계에서 내 최초의 시도는 같은 것이 있었다. 이러한 오버 헤드를 방지하기 위해 나는 2 개 테이블 (제품 및 국가)가있는 경우 단일 localization 테이블이 여기에

product 
------- 
id 
localization_id 


localization  
------- 
id  
local_name 
local_description 
locale_id 


locale 
------ 
id 
locale 

이 스키마에 저장 될 데이터의 예 필요한 있도록 스키마를 재 설계 필요로하는 현지화 :

국가

id,  localization_id 
----------------------- 
1,  5 

제품

,515,
id,  localization_id 
----------------------- 
1,  2 

제이션

id,  local_name, local_description,  locale_id 
------------------------------------------------------ 
2,  apple,  a delicious fruit,  2 
2,  pomme,  un fruit délicieux, 3 
2,  apfel,  ein köstliches Obst, 4 
5,  ireland,  a small country,  2 
5,  irlande,  un petite pay,   3 

로케일

id,  locale 
-------------- 
2,  en 
3,  fr 
4,  de 

localization 테이블의 화합물을 기본 키 (id, locale_id)이지만 product 표 외래 키만을 지칭 공지 것을 이 화합물 PK의 첫 번째 요소 이것은 정규화의 POV에서 '나쁜 것'처럼 보입니다.

이 문제를 해결할 수있는 방법이 있습니까? 아니면 각 지역화 가능 테이블에 별도의 테이블을 만들지 않고도 현지화를 지원하는 완전히 다른 스키마가 있습니까?

업데이트 : 많은 응답자가 각 지역화 가능 테이블에 대해 별도의 테이블을 만들어야하는 솔루션을 제안했습니다. 그러나 이것이 내가 피하려고하는 것입니다. 위에서 제안한 스키마는이 문제를 거의 만족스럽게 해결하지만 localization_id 외래 키는테이블에서 해당 기본 키의 일부만 참조한다는 사실에 만족하지 않습니다.

덕분에, 돈

+1

"하지만 localization_id 외래 키는 현지화 테이블에서 해당 기본 키의 일부만 참조한다는 사실에 불만입니다." 문제가 보이지 않으며 제품에서 현지화까지 일대일 관계가 있습니다. 데이터베이스 구조가 요구 사항을 따르고 있으므로 좋은 해결책을 발견했습니다. –

+0

이 게시물은 http://dba.stackexchange.com/ –

답변

1

올바른 방법은, 느낌, 여분의 테이블을 만들 수 있지만 다음 추가 단계를 가서 첫 번째 테이블에서 모든 언어 특정 자원을 제거하는 것입니다.

그래서 당신은 할 것 :

제품

id 
-name removed 
-description removed 

제품 현지화

productid, locale_id, name, description 
------------------------------------------------------ 
1,   3,   pomme, un fruit délicieux 
1,   4,   apfel, ein köstliches Obst 
1,   1,   apple, a delicious fruit 

로케일

id,  locale 
-------------- 
1,  en 
3,  fr 
4,  de 
+0

에 게시해야합니다. 지역화 가능 콘텐츠가 포함 된 테이블이 두 개 이상인 경우이 스키마가 작동하지 않습니다. –

+0

지역화 가능 콘텐츠 당 추가 테이블이 필요합니다. 네가 그걸 해결할 수있을 것 같지 않아. 일부 지역화 가능 테이블에는 이름이나 설명이 없거나, 번역이 필요한 필드가 더 많이있을 수 있습니다. 물론 정규화에 대한 우수 사례는 없습니다. 추가 테이블을 사용하십시오. 이 경우 – DanDan

+0

, 그것은 단지 이름과 설명을 필요로하는 * 모든 * 지역화 할 수있는 테이블이 나는 당신의 제안을 통합하는 스키마를 수정 한 –

3

나는 괜찮다고 생각한다. 제품과 현지화 텍스트 간의 일대 다 관계를 설명하고 있습니다.

제품 테이블에 영어를 역 정규화하는 대신 영어를 현지화해야하는지 궁금합니다.

+0

을 지역화 할 가정하는 것이 안전 –

+2

현지화의 요점은 하나에이된다 "물건"과 이름 사이의 많은 관계. 따라서 "thing"테이블의 참조는 로컬라이제이션 테이블에 대한 완전한 기본 키가 될 수 없기 때문에 관계가 일대일로 제한됩니다. 다 대일 관계를 수행하는 가장 일반적인 방법은 "하나"끝의 식별자를 "many"끝에 게시하는 것입니다. 그러나 여기에서 수행하는 것이 문제가 될 수 있습니다. 그러면 현지화 테이블에서 다음을 수행해야합니다. 느슨하게 정의 된 외래 키 참조를 만들기 위해 여러 테이블을 참조하십시오. – Jay

1

내가 이해하는 한, 둘 이상의 테이블에서 이름과 설명에 동일한 언어 언어를 사용하려는 경우에만 문제가 발생합니다. 이러한 시나리오에서는 현지화 테이블에 prod_id를 추가 할 수 없습니다. 디자인에서 한 가지 더 많은 문제는 동일한 제품에 대해 하나 이상의 언어 현지화를 우아하게 처리 할 수 ​​없다는 것입니다.

현지화가 필요한 유일한 필드 인 경우 다음을 수행 할 수 있습니다.

제품 효과 translation_row_id이 Product_translations.ID translation_id 것에 외래 키를 가리키는 것입니다

(ID, 이름, 설명, tanslation_row_id)

Product_translations (ID, 이름, 설명, LANG_ID, translation_id) 그러나 모든 언어 관련 레코드에 대한 공통 레코드로 사용되는 동일한 테이블의 상위 레코드를 가리 킵니다.

예 기록

제품

(ID, name, description, translation_row_id) 
(p1, apples,a red fruit, tr1) 
(p2, mango, a yellow fruit, tr2) 

Product_translations

(ID, name, description, lang_id, translation_id) 
(tr1, apples, a red fruit, ENU, null) 
(tr2, mango, a yellow fruit, null) 
(tr3, pomme,un fruit rouge, FRA,tr1) 
(tr4, mangue,a yellow fruit, SPA,tr2) 

언어 코드, 당신은 FOLL의 SQL 쿼리

select T.name, T.description 
from product_translations T 
where T.translation_id = 
    (select T2.ID 
     from Product P,Product_translations T2 
     where P.translation_row_id = t2.ID 
    ) 
    and T.lang_id = '&langID'; 
,691를 사용하여 이름과 설명 값을 추출 할 수 있습니다 감안할 때

중요 사항 : 제품 테이블에이 변환이 필요하지 않은 많은 특성이 있다고 가정합니다. '& LANGID는'사용자에게

+0

좋은 제안,이 시도해 볼 수도 있습니다. 그러나 제품 (및 기타 지역화 가능) 테이블에서 이름과 설명이 중복 될 수 있으므로 제거 할 것입니다. 또한 product_translations 테이블은 '번역'과 같이 좀 더 일반적인 것으로 불려야합니다. 실제로는 번역 된 국가, 제품 등이 포함될 것이기 때문입니다. –

2

내가 생각처럼 자신의 선택의 언어 코드를 요청할 것이지만, 다른 방향으로 단계를 갈 것이라고, 모든 열에 대한 현지화 항목이 SQL 쿼리에 대한 매개 변수입니다 그는 번역 :

국가

id,  localization_id 
----------------------- 
1,  5 

제품

id,  name_locale_id, description_locale_id 
---------------------------------------------- 
1,  2,    8 

현지화

id,  locale_id, value 
------------------------------------------------------ 
2,  2    apple 
2,  3    pomme 
2,  4    apfel 
5,  2    ireland 
5,  3    irlande 
8,  2    a delicious fruit 
8,  3    un fruit délicieux 
8,  4    ein köstliches Obst 
9,  2    a small country 
9,  3    un petite pay 

로케일

제이션의 PK는
id,  locale 
-------------- 
2,  en 
3,  fr 
4,  de 

(ID, LOCALE_ID). id는 다른 여러 테이블에서 FK 참조이기도합니다. 원하는 경우 (id, locale_id)에 여전히 고유 색인이있는 한 대리 키를 추가 할 수 있습니다.

좋은 점은 하나의 지역화 테이블이며 스키마가있는 필드에 상관없이 모든 테이블에서 작동한다는 것입니다 (현지화 된 이름과 설명 모두에 국한되지 않음). . 단점은 지역화 테이블을 사용할 때 잠재적 인 성능에 영향을 미칠 수 있습니다. 잠재적으로 여러분은 주어진 locale_id에 대해 모든 것을 캐시 할 수 있습니다. 따라서 항목을 찾을 때 주어진 ID를 찾아야합니다 (캐시가 이미 언어에 기초한 키잉). 또한 항목이 현재 언어 누락, 또는 입력 할 때되는 경우에 익숙해 질 것입니다 제품 테이블에 기본 이름 및 설명 필드를 떠나 고려할 수

, 사용자는 언어를 지정하지 않았습니다. 기존 앱을 이식하는 경우 이미 로케일 정보가없는 값이 이미있을 것입니다.