MySQL - 如何存储未知和不同大小的输入？

Question

全部，

我想创建一个表来接收用户输入（UGC）。这个内容的大小可以从单个字符到几百个字。输入将在utf8_unicode_ci中编码，并且可以是拉丁字符或多字节字符。

输入将要被搜索。

（从长期来看，我可能想存储非文本对象 - 图片之类的，但现在让我们专注于UTF8文本。）

在这一点上，我只是构想2个字段的表：一个ID（自动增量INT(10)）和UGC本身。 （我可能需要一些更多的领域，如dateAdded等）

我应该如何构建我的数据库，允许灵活性和性能之间的良好折衷？我可以......

1. 设置一个上限，对字符串的大小，并利用性能&可用性命中。
2. 创建不同尺寸范围（最终类型的）几个表，并通过表名和ID的组合识别每件物品（所以我需要有唯一的ID，表名，表特定的ID中央表）。
3. 我可以单独存储每一个对象，只是有DB店的URL。我怀疑这最终会成为＃2效率较低的版本，但我已经超出了我的深度。

谢谢

JDelage

Answer 1

有一个很好的经验法则 - 和拇指的所有规则是远远不够完善 - 这一直工作得很好我：

• 如果DB“理解”的潜在内容BLOBy场，将其存储在数据库中
• 如果DB没有对内容的理解，至今保存它的外部

有了这一点，我的经验这一点，我劝阻图像等使用BLOB字段。

现在的内容想着的时候，可以是文本，图像或什么的，我敢肯定你的业务逻辑需要一些领域，告诉它如何反正用大字段的内容 - 这是很难想象一个应用程序的在查看数据之后，会将图像视为图像。所以我建议你创建这样的领域，mimetype会想到，并且一个，说，mediumtext领域。您的应用业务逻辑很容易推断出，mimetype='text/plain'意味着文本字段中的数据是有效负载，而mimetype='image/png'意味着文本字段中的数据是文件资源的（相对）路径。

如果您以某种方式创建文件路径，那么这不会成为任何语言的单词，这使您可以在内容上进行搜索和索引，错误匹配的可能性很低。想起了MD5(basename).suffix。

Answer 2

既然你也提到了有关存储的图片，建议使用BLOB类型的非文本。 http://dev.mysql.com/doc/refman/5.0/en/blob.html

如果此表使用URL方法占用内容，并且CDN也可能有效，但很明显，您正在处理额外成本和一些编程工作来处理CDN。

Answer 3

对于你在寻找一个varchar什么某些方面似乎是最好的选择，但是当涉及到存储的图片或二进制对象就不会那么好，除非你将其存储在文件系统上，并使用该字段来保存对象的路径。否则，您可能需要使用varchar和blob字段。