다국어 데이터베이스 디자인에 대한 모범 사례는 무엇입니까?

다국어 데이터베이스 디자인에 대한 모범 사례는 무엇입니까? [닫은]

---

다국어 데이터베이스를 만드는 가장 좋은 방법은 무엇입니까? 모든 테이블에 대해 지역화 된 테이블을 만들려면 디자인과 쿼리가 복잡해집니다. 다른 경우에는 각 언어에 대한 열을 추가하는 것이 간단하지만 동적 인 것은 아닙니다. 엔터프라이즈 응용 프로그램에 가장 적합한 선택을 이해하도록 도와주세요.

---

우리가하는 일은 각 다국어 개체에 대해 두 개의 테이블을 만드는 것입니다.

예를 들어 첫 번째 테이블에는 언어 중립적 데이터 (기본 키 등) 만 포함되고 두 번째 테이블에는 현지화 된 데이터와 해당 언어의 ISO 코드가 포함 된 언어 당 하나의 레코드가 포함됩니다.

경우에 따라 DefaultLanguage 필드를 추가하여 지정된 언어에 대해 현지화 된 데이터를 사용할 수없는 경우 해당 언어로 대체 할 수 있습니다.

예:

Table "Product":
----------------
ID                 : int
<any other language-neutral fields>


Table "ProductTranslations"
---------------------------
ID                 : int      (foreign key referencing the Product)
Language           : varchar  (e.g. "en-US", "de-CH")
IsDefault          : bit
ProductDescription : nvarchar
<any other localized data>

이 방법을 사용하면 새로운 언어마다 필드를 추가 할 필요없이 필요한만큼 언어를 처리 할 수 ​​있습니다.

---

업데이트 (2014-12-14) : 다국어 데이터를 응용 프로그램에로드하는 데 사용되는 구현에 대한 추가 정보 는 이 답변을 참조하십시오 .

---

Martin이 게시 한 답변을 추천합니다.

그러나 쿼리가 너무 복잡 해지는 것에 대해 걱정하는 것 같습니다.

모든 테이블에 대해 지역화 된 테이블을 만들려면 디자인과 쿼리를 복잡하게 만듭니다.

따라서 다음과 같은 간단한 쿼리를 작성하는 대신 생각할 수도 있습니다.

SELECT price, name, description FROM Products WHERE price < 100

... 다음과 같은 쿼리 작성을 시작해야합니다.

SELECT
  p.price, pt.name, pt.description
FROM
  Products p JOIN ProductTranslations pt
  ON (p.id = pt.id AND pt.lang = "en")
WHERE
  price < 100

아주 예쁜 관점은 아닙니다.

그러나 수동으로 수행하는 대신 특수 지역화 마크 업이 포함 된 SQL을 미리 구문 분석하여 데이터베이스로 보내야하는 실제 SQL로 변환하는 자체 데이터베이스 액세스 클래스를 개발해야합니다.

해당 시스템을 사용하면 다음과 같이 보일 수 있습니다.

db.setLocale("en");
db.query("SELECT p.price, _(p.name), _(p.description)
          FROM _(Products p) WHERE price < 100");

그리고 더 잘할 수 있다고 확신합니다.

중요한 것은 테이블과 필드의 이름을 균일하게 지정하는 것입니다.

---

이 유형의 접근 방식이 저에게 효과적이라는 것을 알았습니다.

제품 제품 세부 국가
========= =================== =========
ProductId ProductDetailId CountryId
-기타-ProductId CountryName
            CountryId 언어
            제품 이름-기타-
            제품 설명
            -등-

The ProductDetail table holds all the translations (for product name, description etc..) in the languages you want to support. Depending on your app's requirements, you may wish to break the Country table down to use regional languages too.

---

I'm using next approach:

Product

ProductID OrderID,...

ProductInfo

ProductID Title Name LanguageID

Language

LanguageID Name Culture,....

---

Martin's solution is very similar to mine, however how would you handle a default descriptions when the desired translation isn't found ?

Would that require an IFNULL() and another SELECT statement for each field ?

The default translation would be stored in the same table, where a flag like "isDefault" indicates wether that description is the default description in case none has been found for the current language.

참고URL : https://stackoverflow.com/questions/929410/what-are-best-practices-for-multi-language-database-design