我正在为我的数据库添加对多种语言的支持。它有大约 10 个不同结构的表。我绘制了下面的结构，我认为这是一个好方法：
表语言：
lang_id (int)
lang_name (varchar 128)
表样本 1：
sample_1_id (int)
name (int -- tran_id)
description (int -- tran_id )
表样本 2：
sample_2_id (int)
person (int -- tran_id)
page (int -- tran_id)
表翻译：
tran_id (int)
lang_id (int)
content (text)
但是，为了全面开展这项工作，翻译表中的内容列是否必须是“文本”类型？如果是这样，那会不会浪费空间，尤其是当其中存储的大部分数据只是几个字符时？有没有更好的办法？
考虑两个翻译表。像这样的一个：
Translations_Short:
tran_id (int)
lang_id (int)
content (VARCHAR(255))
请注意，MySQL 5.0.3+ 中 VARCHAR 的限制实际上是 65,535 字节，尽管这也是行限制。所以，你可以使用：
tran_id (int)
lang_id (int)
content (VARCHAR(65522))
还有一个是这样的：
翻译_长：
tran_id (int)
lang_id (int)
content (text)
TEXT 只有 65535，所以在 MySQL 5.0.3+ 中，这已经被覆盖了。你也可以在这里使用 MEDIUMTEXT。
然后，您可以像这样决定每列：
sample_1_id (int)
name (int -- tran_long_id)
description (int -- tran_short_id )
您的应用程序会知道要链接到哪一个，对吗？
无论如何，TEXT 并没有比 VARCHAR 占用更多的空间。也许是一两个字节。问题是性能，而不是空间。由于您不会为 TEXT 列编制索引，因此这也不太可能成为问题，除非您计划使用覆盖索引（这在 TEXT 中是不可能的）。无论如何，VARCHAR 的索引限制为 767 字节，因此您不能使用 VARCHAR 列超过 767 字节的覆盖索引。
但是，如果您真的认为有必要，这将允许您将它们分开。
这个怎么样......让我们以“页面”表为例。
主“页”表：
id - 主要
关联
一个约会
约会
地位
ETC...
翻译“ pages_langs ”表：
page_id - 主要的
lang_id - “语言”表，例如 1 ** 这里所有你想要管理的翻译 **
title - 页面的标题，例如 lang_id=1
文本
term - （该术语用于 url beautify 和类似的东西，需要在 langs 表中）
“语言”表：
id - 主要
标题
字首
SELECT 将是这样的：
SELECT p.id, p.link, pl.title, pl.text
FROM pages
INNER JOIN pages_langs pl ON p.id = pl.page_id AND pl.lang_id = <<current lang id>>
任何问题？