0

我正在设计一个程序，用户可以在数千（或可能数百万）人中做出单一选择。我想到了两种将其存储在数据库中的方法：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

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

感谢您的输入。

4

2 回答 2

1

我会将我的评论放在答案中并在某些地方进行扩展。

关于你对stringvs的决定Table。每次一桌。

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

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

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

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

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

于 2012-05-17T10:35:56.553 回答
0

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

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

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

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

于 2012-05-17T10:50:09.370 回答