10

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

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

4

8 回答 8

13

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

于 2009-09-17T12:17:00.013 回答
9

你提到的字符串一点都不长。

当您提到“长”字符串时，我在考虑 32kB 及以上——有些句子小于 1kb——今天什么都不是。

您的技巧是存储 Id 会使事情变慢，因为您必须进行间接访问。

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

于 2009-09-17T12:29:49.877 回答
4

我会创建一个单独的表的唯一原因是这些长字符串对于许多记录来说是否相同。否则，它只是一个额外的并发症，不太可能提供任何回报。

于 2009-09-17T12:17:52.337 回答
3

五六个句子对于现代 DBMS 来说不算什么！将文本直接存储在数据库中。

（您提到的另一种技术 - 将引用存储到另一个表，该表本身具有对保存文本的外部文件的引用 - 使用起来会更加麻烦并且性能要差得多。）

于 2009-09-17T12:16:56.940 回答
2

答案实际上取决于您打算存储的字符串的数量，以及您打算使用什么数据库来存储它。如果您不存储很多字符串，您可能需要考虑将它们存储在 XML 或资源文件中，然后将其加载到您的应用程序中。但是，如果您有大量字符串数据，则最好在需要时以内存方式读取字符串，而不是冒险将字符串读入您最终不会使用的内存中。

于 2009-09-17T12:19:02.240 回答
2

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

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

只有当您的应用程序/数据模型直接受益于这种方法时，才会出现是否将它们分开并为其附加 ID 的问题，即实际上它们是独立的事物。在您的情况下，似乎没有理由这样做。

于 2009-09-17T12:19:13.690 回答
1

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

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

于 2009-09-17T13:13:54.517 回答
0

除非在特殊情况下，我会离开现场。

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

于 2009-09-17T12:19:28.680 回答