将长字符串存储在数据库中是否好？

Question

我需要在数据库中存储长字符串。该字符串可能长5或6个句子。你认为这是一个好的设计策略吗？或者我应该为该字符串存储一个id，然后与另一个包含存储该字符串的文件位置的表创建关系。 可以请你给两者的优点和缺点。

字符串已被预处理并存储在数据库中。任何修改都会读取整个字符串并完全替换它。所以你可以假设这个字符串是不可分割的。

Answer 1

它应该可以将字符串存储在数据库中。如果您存储文件指针，则意味着每次要读取字符串时都需要执行文件I/O。几句话不是很长，如果需要的话，你总是可以使用长文本数据字段。显然你的数据库会有点大，因为你有文本，但没关系。这肯定是比存储文件更好的选择。

Answer 2

五六句话对现代DBMS来说没有什么意义！将文本直接存储在数据库中。 （你提到的另一种技术 - 存储裁判本身具有裁判外部文件来保存文本另一个表 - 会更麻烦的使用，并有更差的表现。）

Answer 3

我会创建一个单独的表的唯一原因是，如果这些长字符串将为许多记录相同。否则，它只是一个额外的复杂性，不可能提供任何回报。

Answer 4

答案真的取决于你打算存储的字符串的数量，以及你打算用来存储它的数据库。如果你没有存储多个字符串，你可能会考虑将它们存储在XML或资源文件中，并将其加载到应用程序中。如果你有很多字符串数据，你可能会更好地在内存中读取字符串，而不是在你需要的时候读取字符串，而不是将字符串读入内存中。

Answer 5

数据库本身没有存储长字符串的实际问题。有些限制适用（例如SQL Server上的8k记录大小限制），但即使这样，您也可以将任意长度的文本存储在数据库中，因为所有正确的文本都支持BLOB/TEXT数据类型，但实际上没有上限。

五到六句话不是很长。如果它们属于一个整体，并且要作为一个整体进行检索和操作，则可以继续并将它们存储在适当维度的CHAR数据类型字段中。

仅当您的应用程序/数据模型直接从此方法中受益时，是否将它们分开并附加ID才会出现问题，即实际上它们是单独的事物。在你的情况下，似乎没有理由走这条路。

Answer 6

除特殊情况外，我会离开现场。

唯一的其他选择是将字符串放入不同的表（将实际的字符串放在那里）......将它们放在单独的文件中将会导致性能下降。

Answer 7

你提到的字符串并不长。

当你提到“long”字符串时，我想到的是32kB及以上 - 有些句子是< 1kb - 今天没有什么了。

你的技巧，存储一个Id会让事情变得更慢，因为你必须进行间接访问。

当需要最大性能时，我应该推荐的唯一方法是只选择那些需要的列（省略SELECT *） - 因此在不需要时省略文本列，因为字符串从服务器到应用程序的花费最多。这是一个很好的实践，不要触摸不需要的列（特别是当它们可能包含大量数据时）。

Answer 8

大家都提到过性能，但没有人提出存储指向操作系统文件的指针是一个坏主意的另一个主要原因：备份和恢复。如果一切都在数据库中，那么我们有一个备份数据的机制和一个用于恢复的机制。而对于操作系统上的文件，我们有两种不同的备份机制，可能有两种不同的粒度，恢复成为同步噩梦。

有一些情况不适用，例如数据仓库，这些数据仓库事务非常罕见，因此无需重做或事务日志即可生存。