29

Tôi cần tạo một Mô hình DB có quy mô lớn cho một ứng dụng web sẽ đa ngôn ngữ.Mô hình hóa cơ sở dữ liệu cho các mục đích quốc tế và đa ngôn ngữ

Một nghi ngờ rằng mỗi lần tôi nghĩ về cách thực hiện nó là cách tôi có thể giải quyết có nhiều bản dịch cho một trường. Một ví dụ điển hình.

Bảng cho cấp độ ngôn ngữ, quản trị viên có thể chỉnh sửa từ chương trình phụ trợ, có thể có nhiều mục như: cơ bản, nâng cao, thông thạo, mattern ... Trong tương lai gần, có thể đó sẽ là một loại nữa. Các quản trị viên đi đến phụ trợ và thêm một cấp độ mới, nó sẽ sắp xếp nó ở vị trí bên phải .. nhưng làm thế nào tôi xử lý tất cả các bản dịch cho người dùng cuối cùng? Một vấn đề khác với việc quốc tế hóa một cơ sở dữ liệu là có thể cho các nghiên cứu người dùng có thể khác nhau từ Mỹ đến Anh để DE ... ở mọi quốc gia họ sẽ có cấp độ của họ (có thể nó sẽ tương đương với một cấp độ khác nhưng cuối cùng, khác nhau) . Và những gì về thanh toán?

Cách bạn lập mô hình này ở quy mô lớn?

+3

Lưu ý phụ, đảm bảo bạn tạo bảng bằng mã hóa UTF-8. –

+0

Bạn đang sử dụng công nghệ nào? Hầu hết các khung công tác hiện có quản lý i18n khá tốt. – sp00m

+0

@ sp00m: Tôi đang sử dụng PHP. Không có vấn đề với ngôn ngữ của trang web, ngôn ngữ "tĩnh". Tôi yêu cầu những thứ mà quản trị viên có thể thêm từ chương trình phụ trợ của trang web ... khi thêm họ không thể thêm 15 ngôn ngữ cho chỉ 1 mục. Có lẽ nói về ngôn ngữ/language_levels về chủ đề này cũng không đúng. Hay bạn đang nói rằng quản lý tốt i18n trên cơ sở dữ liệu? Cảm ơn! – udexter

Trả lời

48

Dưới đây là cách tôi sẽ thiết kế cơ sở dữ liệu:

Data model

Visualization bởi DB Designer Fork

Bảng i18n chỉ chứa một PK, do đó bất kỳ bảng chỉ phải tham chiếu đến PK này để quốc tế hóa một trường. Bảng translation sau đó chịu trách nhiệm liên kết ID chung này với danh sách bản dịch chính xác.

locale.id_localeVARCHAR(5) để quản lý cả hai enen_USISO syntaxes.

currency.id_currencyCHAR(3) để quản lý ISO 4217 syntax.

Bạn có thể tìm thấy hai ví dụ: pagenewsletter. Cả hai đối tượng địa lý quản trị viên được quản lý này cần phải quốc tế hóa các trường của mình, tương ứng title/descriptionsubject/content.

Dưới đây là một truy vấn Ví dụ:

select 
    t_subject.tx_translation as subject, 
    t_content.tx_translation as content 

from newsletter n 

-- join for subject 
inner join translation t_subject 
    on t_subject.id_i18n = n.i18n_subject 

-- join for content 
inner join translation t_content 
    on t_content.id_i18n = n.i18n_content 

inner join locale l 

    -- condition for subject 
    on l.id_locale = t_subject.id_locale 

    -- condition for content 
    and l.id_locale = t_content.id_locale 

-- locale condition 
where l.id_locale = 'en_GB' 

    -- other conditions 
    and n.id_newsletter = 1 

Lưu ý rằng đây là một mô hình dữ liệu bình thường. Nếu bạn có một tập dữ liệu khổng lồ, có thể bạn có thể suy nghĩ về denormalizing it để tối ưu hóa các truy vấn của mình. Bạn cũng có thể chơi với các chỉ mục để cải thiện hiệu suất truy vấn (trong một số DB, các khóa ngoại được tự động lập chỉ mục, ví dụ: MySQL/InnoDB).

+1

OK, giải thích rất dễ hiểu và hữu ích. Câu hỏi duy nhất tôi có - sẽ không phải là tốn kém trong ý nghĩa của bộ nhớ và tài nguyên máy chủ để sử dụng loại TEXT cho mỗi chuỗi địa phương? –

+0

@f_martinez Tôi đoán nó phụ thuộc vào dữ liệu bạn cần lưu trữ. Nhưng cảm thấy tự do để sử dụng loại bạn cần, nếu nó có thể phù hợp trong một varchar ví dụ. – sp00m

+6

Không trộn ** tiền tệ ** và ** bản dịch **. – gavenkoa

27

Một số câu hỏi StackOverflow trước về chủ đề này:

Một số nguồn lực bên ngoài hữu ích:

Cách tiếp cận tốt nhất thường được, cứ mỗi bảng hiện có, tạo một bảng mới vào các mục văn bản được chuyển; PK của bảng mới là PK của bảng cũ cùng với ngôn ngữ.

Trong trường hợp của bạn:

  1. Bảng cho các mức độ ngôn ngữ, các quản trị viên có thể chỉnh sửa từ phụ trợ, có thể có nhiều mặt hàng như: cơ bản, trước, thành thạo, MATTERN ... Trong gần tương lai có lẽ nó sẽ là một loại nữa. Các quản trị viên đi đến phụ trợ và thêm một cấp độ mới, nó sẽ sắp xếp nó ở vị trí bên phải .. nhưng làm thế nào tôi xử lý tất cả các bản dịch cho người dùng cuối cùng?

    bảng hiện tại của bạn có thể trông giống như sau:

     
    +----+-------+---------+ 
    | id | price | type | 
    +----+-------+---------+ 
    | 1 | 299 | basic | 
    | 2 | 299 | advance | 
    | 3 | 399 | fluent | 
    | 4 |  0 | mattern | 
    +----+-------+---------+ 
    

    Sau đó nó trở thành hai bảng:

     
    +----+-------+ +----+------+-------------+ 
    | id | price | | id | lang | type  | 
    +----+-------+ +----+------+-------------+ 
    | 1 | 299 | | 1 | en | basic  | 
    | 2 | 299 | | 2 | en | advance  | 
    | 3 | 399 | | 3 | en | fluent  | 
    | 4 |  0 | | 4 | en | mattern  | 
    +----+-------+ | 1 | fr | élémentaire | 
           | 2 | fr | avance  | 
           | 3 | fr | couramment | 
           : :  :    : 
           +----+------+-------------+ 
    
  2. Một vấn đề khác với internationalitzation của một cơ sở dữ liệu là có thể cho người sử dụng các nghiên cứu có thể khác nhau từ Hoa Kỳ đến Vương quốc Anh để DE ... ở mọi quốc gia họ sẽ có trình độ của họ (có thể nó sẽ tương đương với cấp độ khác nhưng fi nally, khác nhau). Và những gì về thanh toán?

    Mọi nội dung bản địa hóa có thể xảy ra thông qua cách tiếp cận tương tự. Thay vì chỉ di chuyển trường văn bản sang bảng mới, bạn có thể di chuyển bất kỳ trường địa phương nào - chỉ những trường chung chung với tất cả các ngôn ngữ sẽ vẫn còn trong bảng gốc.