我需要爲多語言Web應用程序創建大型數據庫模型。用於國際和多語言目的的數據庫建模
有一個疑問，我每次想到如何做到這一點，就是我如何解決一個領域的多個翻譯問題。一個案例。
管理員可以從後端編輯的語言級別表可以包含多個項目，如：basic，advance，fluent，mattern ...在不久的將來，它可能會是另外一種類型。管理員進入後端並添加一個新的級別，它會將其排序在正確的位置..但我如何處理最終用戶的所有翻譯？
數據庫國際化的另一個問題是，用戶研究可能會有所不同，從美國到英國到德國......在每個國家，他們都會有自己的水平（這可能會相當於另一個國家，但最後會有所不同） 。那麼結算呢？
如何在大範圍內建模？
這裏是我設計數據庫的方式：
可視化的DB Designer Fork
的i18n表只包含一個PK，讓任何表只是要參考這個PK來實現一個領域的國際化。表translation然後負責將該通用ID與正確的翻譯列表關聯起來。
locale.id_locale是VARCHAR(5)來管理的en和en_USISO syntaxes。
currency.id_currency是CHAR(3)來管理ISO 4217 syntax。
您可以找到兩個示例：page和newsletter。這兩個管理員管理的實體需要國際化其領域，分別爲title/description和subject/content。
下面是一個例子查詢：
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
注意，這是一個標準化的數據模型。如果你有一個龐大的數據集，也許你可以考慮denormalizing it來優化你的查詢。您還可以使用索引來提高查詢性能（在某些DB中，外鍵會自動編入索引，例如MySQL/InnoDB）。
有關這個主題的一些先前StackOverflow的問題：
個一些有用的外部資源：
最好的辦法通常是，對於每一個現有的表，創建成文本項移動新表;新表的PK是舊錶的PK和語言一起的。
你的情況：
對語言水平的表中，管理員可以從後臺編輯，可以有多個項目，如：基本，高級，流利，Mattern的......在不久的未來可能它會成爲一種類型。管理員進入後端並添加一個新的級別，它會將其排序在正確的位置..但我如何處理最終用戶的所有翻譯？
你現有的表可能看起來是這樣的：
+----+-------+---------+ | id | price | type | +----+-------+---------+ | 1 | 299 | basic | | 2 | 299 | advance | | 3 | 399 | fluent | | 4 | 0 | mattern | +----+-------+---------+
然後它變成兩個表：
+----+-------+ +----+------+-------------+
| 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 |
: : : :
+----+------+-------------+
與數據庫的internationalitzation另一個問題是，可能是用戶研究可以有所不同，從美國到英國到DE ...在每個國家，他們將有他們的水平（這可能會相當於另一個，但fi最後，不同）。那麼結算呢？
所有本地化都可以通過類似的方法發生。不僅僅是將文本字段移動到新表中，您可以移動任何可本地化的字段 - 只有那些對所有語言環境通用的字段纔會保留在原始表中。
請注意，請確保使用UTF-8編碼創建表格。 –
你使用什麼技術？現有的大多數框架都能很好地管理i18n。 – sp00m
@ sp00m：我正在使用PHP。網站的語言，即「靜態」語言沒有問題。我要求管理員可以從網站的後端添加的內容...添加時，他們無法僅爲1項添加15種語言。大概在這個話題上談論語言/ language_levels是不對的。或者你是否也在說管理i18n對數據庫有好處？謝謝！ – udexter