logo标签列表

在数据库中存储长字符串是否可行？

databaseperformancestringlong-integer
11

我需要将长字符串存储到数据库中，这些字符串可能包含5或6个句子。您认为这是一个好的设计策略吗？还是应该为该字符串存储一个ID，并创建一个与另一个包含存储字符串文件位置的表的关系。

请列出两种方法各自的优缺点。

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

1
事实上，这就是为什么SQL有TEXT类型（哦，还有CLOB）的原因。 - Powerlord
8个回答
13

在数据库中存储字符串应该是可行的。如果存储文件指针，这意味着每次要读取字符串时都需要进行文件I/O。几句话并不是非常长，并且如果需要的话，您可以始终使用longtext数据字段。显然，由于存在文本，您的数据库会稍微变大，但那没关系。这肯定比必须存储文件要好。

9

您提到的字符串并不算长。

当您提到“长”字符串时，我想到的是32kB及以上的字符串 - 有些句子不到1kb - 在今天来说这根本算不上什么。

您的技巧是存储一个ID，但这会使事情变慢，因为您需要进行间接访问。

唯一建议的是，在需要最大性能时，只选择您需要的列（省略SELECT *） - 因为从服务器传输字符串到应用程序需要最多的时间，所以在不需要时省略文本列。不要触碰不需要的列（特别是当它们可能包含大量数据时），这是一个好的做法。

5

我只会在很多记录中使用相同的长字符串时才会创建单独的表格。否则，这只是一个额外的复杂性，不太可能提供任何回报。

不，这些长字符串是不同的。我理解你的观点，不应该使用单独的表。但是，我应该将字符串存储在文件系统中，并仅在数据库中保存指向该文件的指针，还是将字符串本身存储在数据库中。有任何基于性能的建议吗？ - Rohit Banga
@iamrohitbanga：那么，它们有多长呢？任何不超过几千字节（对于文本来说相当多）的内容都可以存储在数据库中。超过该限制的任何内容仍然可以存储，但您必须使用DBMS提供的TEXT数据类型。出于性能原因将它们放到文件系统中的想法对我来说并没有太多意义。 - Tomalak
@iamrohitbanga：这些字符串确实需要相当大的尺寸，我们谈论的是数以万计的倍数，只有在存储它们带来的所有复杂性之后才能在文件系统中存储它们，如果真的有必要的话。 - AnthonyWJones
3

对于现代数据库管理系统来说，五六个句子根本不算什么！可以直接将文本存储在数据库中。

（你提到的另一种技术——将引用存储到另一个表中，该表本身具有引用外部文件保存文本的方式——使用起来会更加麻烦，并且性能也会大大降低。）

"对于现代数据库管理系统而言，五到六十亿条语句根本不算什么!" - Xeoncross
2

答案取决于您要存储的字符串数量以及您打算使用的数据库。如果您不存储太多字符串，您可以考虑将它们存储在XML或资源文件中，并在应用程序启动时将其加载。但是，如果您有大量的字符串数据，最好根据需要读取字符串，而不是冒险将您不使用的字符串读入内存。

2
数据库本身没有存储长字符串的问题。虽然有一些限制（如SQL Server上的8k记录大小限制），但即使如此，您也可以在数据库中存储任意长度的文本，因为所有合适的数据库都支持BLOB / TEXT数据类型，几乎没有上限。
五到六个句子并不算太长。如果它们属于同一个整体，并且需要检索和操作，那么您可以将它们存储在适当尺寸的CHAR数据类型字段中。
只有在您的应用程序/数据模型直接从这种方法中获益时，即它们实际上是分开的东西时，才会出现将它们分开并附加ID的问题。在您的情况下，似乎没有理由采取这种方法。
1

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

有一些情况不适用于此，例如数据仓库，其事务非常少，因此可以在没有重做或事务日志的情况下生存。

0

除非特殊情况，否则我会让字段保持原样。

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

网页内容由stack overflow 提供, 点击上面的
可以查看英文原文，
原文链接