Thực hành tốt nhất cho thiết kế cơ sở dữ liệu đa ngôn ngữ là gì? [đóng cửa]

Cách tốt nhất để tạo cơ sở dữ liệu đa ngôn ngữ là gì? Để tạo bảng được bản địa hóa cho mỗi bảng làm cho thiết kế và truy vấn trở nên phức tạp, trong trường hợp khác, việc thêm cột cho mỗi ngôn ngữ là đơn giản nhưng không động, vui lòng giúp tôi hiểu đâu là lựa chọn tốt nhất cho các ứng dụng doanh nghiệp

Những gì chúng ta làm, là tạo hai bảng cho mỗi đối tượng đa ngôn ngữ.

Ví dụ: bảng đầu tiên chỉ chứa dữ liệu trung lập ngôn ngữ (khóa chính, v.v.) và bảng thứ hai chứa một bản ghi cho mỗi ngôn ngữ, chứa dữ liệu được bản địa hóa cộng với mã ISO của ngôn ngữ.

Trong một số trường hợp, chúng tôi thêm trường Ngôn ngữ mặc định, để chúng tôi có thể quay lại ngôn ngữ đó nếu không có dữ liệu địa phương hóa cho một ngôn ngữ được chỉ định.

Thí dụ:

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>

Với phương pháp này, bạn có thể xử lý bao nhiêu ngôn ngữ khi cần (mà không phải thêm các trường bổ sung cho mỗi ngôn ngữ mới).

Cập nhật (2014-12-14): vui lòng xem câu trả lời này , để biết thêm thông tin về việc triển khai được sử dụng để tải dữ liệu đa ngôn ngữ vào một ứng dụng.

Tôi đề nghị câu trả lời được đăng bởi Martin.

Nhưng bạn dường như lo ngại về các truy vấn của mình trở nên quá phức tạp:

Để tạo bảng được bản địa hóa cho mỗi bảng, hãy thiết kế và truy vấn phức tạp ...

Vì vậy, bạn có thể nghĩ rằng, thay vì viết các truy vấn đơn giản như thế này:

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

... bạn sẽ cần bắt đầu viết các truy vấn như thế:

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

Không phải là một quan điểm rất đẹp.

Nhưng thay vì thực hiện thủ công, bạn nên phát triển lớp truy cập cơ sở dữ liệu của riêng mình, đó là phân tích trước SQL có chứa đánh dấu nội địa hóa đặc biệt của bạn và chuyển đổi nó thành SQL thực tế mà bạn sẽ cần gửi đến cơ sở dữ liệu.

Sử dụng hệ thống đó có thể trông giống như thế này:

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

Và tôi chắc chắn rằng bạn có thể làm tốt hơn thế.

Điều quan trọng là để các bảng và trường của bạn được đặt tên theo cách thống nhất.

Tôi thấy cách tiếp cận này hiệu quả với tôi:

Sản phẩm Sản phẩm Đất nước
========= ================== =========
ProductId ProductDetailId CountryId
- vv - ProductId CountryName
            Ngôn ngữ quốc gia
            Tên sản phẩm - vv -
            Mô tả Sản phẩm
            - Vân vân -

Bảng ProductDetail chứa tất cả các bản dịch (cho tên sản phẩm, mô tả, v.v.) bằng các ngôn ngữ bạn muốn hỗ trợ. Tùy thuộc vào yêu cầu của ứng dụng của bạn, bạn có thể muốn chia bảng Quốc gia để sử dụng các ngôn ngữ trong khu vực.

Tôi đang sử dụng phương pháp tiếp theo:

Sản phẩm

ProductID OrderID, ...

Thông tin sản phẩm

Tên sản phẩm Tên ngôn ngữID

Ngôn ngữ

Tên ngôn ngữ Văn hóa, ....

Giải pháp của Martin rất giống với giải pháp của tôi, tuy nhiên bạn sẽ xử lý các mô tả mặc định như thế nào khi bản dịch mong muốn không được tìm thấy?

Điều đó có yêu cầu IFNULL () và một câu lệnh CHỌN khác cho mỗi trường không?

Bản dịch mặc định sẽ được lưu trữ trong cùng một bảng, trong đó một cờ như "isDefault" chỉ ra rằng mô tả đó là mô tả mặc định trong trường hợp không tìm thấy ngôn ngữ hiện tại.