LONG TEXT 或数千行，或者其他什么？答案

【问题标题】：LONG TEXT or thousands of rows, or maybe something else?LONG TEXT 或数千行，或者其他什么？
【发布时间】：2023-04-02 15:35:01
【问题描述】：

我正在设计一个程序，用户可以在数千（或可能数百万）人中做出单一选择。我想到了两种将其存储在数据库中的方法： 1) 每个条目单独一行 2) 一个长文本，只是为新人附加一个选择或修改一个现有人的选择。

我想每个条目的单独行应该更有效，但如果我们谈论的是，比如说，数十万个条目，那么我正在寻找的网络开销是多少？只返回一个长文本并使用用户的 cpu 解析文本？

例如，单个长文本可能类似于：

Data
[Person A:Choice A][Person B: Choice A][Person C: Choice C]...[Person n:Choice n]

而多行显然是：

Person    Choice
A         A
B         A
C         C
....
n         n

也许我一开始就没有以正确的方式思考这个问题。有没有更有效的方法来做这样的事情？

感谢您的意见。

【问题讨论】：

表每次。表Person，表Choice，表PersonChoice 包含每个相应表的ID，显示所做的选择。可索引、可搜索、灵活。
我想我还应该补充一点，用户将能够查看他/她对每个人所做选择的总体统计信息，因此无论如何我都必须访问用户的所有选择。在这种情况下，你还会推荐这些桌子吗？
当然，在 SQL 的文本列中隐藏数据是一个非常糟糕的主意。要保存 1000 行，也许调查选择组，以减少行？很快就会有人出现，并且比我更简洁地提出这个论点！
我想肯定比你说的要多。用户不可能对 数百万 人进行选择，除非他们以某种方式分组。在这种情况下，您可以查看进一步分解结构Person --> Group --> Choice1 | Choice2 etc。否则我会建议桌子，它更灵活。如果您真的担心性能，您可以设置一个夜间作业将您的主表格式化为长字符串，但这只有在您的数据不是很可变的情况下才真正起作用。
谢谢 -- 我故意没有提供所有细节，但提供的信息对我来说已经足够了，根据你所说的，再加上一些谷歌搜索。

【解决方案1】：

我会将我的 cmets 放在一个答案中并在某些地方扩展。

关于您对string 与Table 的决定。每次都上桌。

基于表Person (Id, Name)、表Choice (Id, Value)和表PersonChoice (Id, PersonId, ChoiceId)的设计。将为您提供可索引、可搜索和灵活的解决方案。

在 SQL 的文本列中隐藏数据是一个非常糟糕的主意 - 显然忽略了 XML 数据及其数据类型。但这不适用于这里。

在以后添加统计信息的一种解决方案可能是安排 SQL 代理作业运行数据，解析更改的内容和时间，并将该数据存储在单独的“报告”表中。

在您的设计中需要考虑的一点是——为了省去存储和操作 1000 行的麻烦——是将选择组合在一起的想法。可以为您节省大量工作（为您自己和服务器）。

欢迎来到数据库设计的世界！

【讨论】：

我只是建议您从 PersonChoice 表中删除 Id，因为表的 PK 将是 PersonId,ChoiceId 并且将每个 Id 作为各自表的 FK。就像我说的一样，只是一个小建议

【解决方案2】：

我想每个条目的单独行应该更有效，但是如果我们谈论的是，比方说，数十万个条目，那么我正在寻找的网络开销是多少而不是只返回一个长文本并使用用户的 cpu 来解析文本？

网络开销（作为两种设计之间的差异）可以忽略不计。本质上，您向服务器发送的所有内容都是您的查询，而服务器返回的所有内容都是结果集。如果您的查询结果是一行，则服务器只返回一行。如果您的查询结果是 10,000 行，则服务器会发回 10,000 行。

真正的开销在于服务器上的执行速度和维护。如果您使用索引，服务器将快速找到表中的索引行。但是在像“1, 2, 3, 5, 6, 7, 8, 10, 13, 17, 18, 30, 27” 这样的单个值中找到 17 可能不会使用索引。

这样的值也会失去类型安全以及使用外键引用和级联的能力。

【讨论】：