我正在设计一个程序，用户可以在数千（或数百万）人中做出单一选择。我想到了两种在数据库中存储它的方法： 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
也许我一开始并没有以正确的方式思考这个问题。有没有更有效的方式做这样的事情？
感谢您的意见。
答案 0 :(得分：1)
我会将我的评论放在答案中并扩展到某些地方。
关于string vs Table的决定。每次都有表。
基于表格Person (Id, Name)，表格Choice (Id, Value)和表格PersonChoice (Id, PersonId, ChoiceId)的设计。将为您提供可索引，可搜索和灵活的解决方案。
在SQL中的文本列中隐藏数据是一个非常糟糕的主意 - 显然忽略了XML数据及其数据类型。但这不适用于此。
以后添加统计信息的一种解决方案可能是运行数据的计划SQL代理作业，解析更改的内容和时间，并将这些数据存储在单独的“报告”表中。
在您的设计中要考虑的事情 - 为了节省自己必须存储和操作1000行 - 是将选择分组在一起的想法。可以为您节省大量工作（包括您自己和服务器）。
欢迎来到数据库设计世界！
答案 1 :(得分：0)
我认为每个条目的单独行应该更有效，但是 如果我们谈论，比方说，成千上万的条目， 然后我正在寻找什么是网络开销的查询 而只是返回一个长文本并使用用户的cpu 解析文本？
网络开销（两种设计之间的差异）可以忽略不计。基本上你发送给服务器的只是你的查询，所有服务器返回的都是结果集。如果查询结果是一行，则服务器只返回一行。如果查询结果为10,000行，则服务器将返回10,000行。
真正的开销是服务器和维护中的执行速度。如果使用索引，服务器将快速在表中查找索引行。但是在单个值中找到17，如“1,2,3,5,6,7,8,10,13,17,18,30,27”可能不会使用索引。
这样的值也会失去类型安全性以及使用外键引用和级联的能力。