我正在创建一个将存储100.000（以及将来可能更多）用户的数据库。虽然这显然发生在每个用户有1行的表中，但每个用户都可以（并且将会）存储数百个项目。在编程语言中，这意味着用户有2个整数数组（或一个二维数组）：itemid的列和数量的列。
我的直觉告诉我要创建一个表来保存所有这些项目，其行如（userid，itemid，amount）。然而，这将导致一个巨大的表。 200.000个用户，每个250个项目......一个表中有5000万个条目。这一点，加上桌子将经历连续快速的变化，让我感到害怕。 （有多快？我估计每秒最多100次修改。）
通常会有100到2000个用户，包括添加和删除项目以及修改金额。这些操作可以并且将在编程代码中发生。它将如下：
值得注意的是，用户可以存储的项目数量最多。
有没有其他方法可以使用单独的表格？也许将值保存在格式化的文本字符串中？或者这是使用MySQL数据库实际上是Bad Idea™的实例之一吗？
感谢您的时间和见解。
答案 0 :(得分：5)
我的直觉告诉我要创建一个表来容纳所有这些项目
你的直觉是正确的。
1）避免过早优化
2）除非你有一个非常好的理由，否则不要违反规范化规则
3）为什么你怀疑多表方法会更快？
一个表中有5000万个条目
那又怎样？即使您只有userid索引，与每个用户的单个表相比，性能差异也不会明显变慢（实际上，有200,000个用户，它会更快，更快 - 因为DBMS可以轻松地保持开放状态每个表的文件句柄！）。
我估计每秒最多100次修改
应该可以使用MySQL和相当基本的硬件，但如果是我，我想要一点空间，我会选择一对镜像SATA磁盘，一面镜子上的表，另一面上的索引。 / p>
我唯一关心的问题（无论你选择哪两个模型都适用）都支持2000个并发连接。连接必须是并发的吗？或者每个用户是否可以下载工作集（可选择使用乐观锁定策略）并关闭连接，然后在新连接上推回更改？如果没有，那么你可能想要一个很好的内存和CPU重击。
但是不管是使用一个大表还是许多小表，如果这是数据的唯一用途，并且访问不是与特定数据项并发，那么为什么还要使用关系数据库呢？ NoSQL或共享文件系统也可以正常工作。
答案 1 :(得分：1)
将数据作为数组放入一个字段几乎总是一个错误。它使得查询数据更加困难，耗时更多，并且使用索引的可能性也大大降低。没关系，如果值只是文本，你永远不需要找到数组的一个或多个元素，但我的经验是很少遇到这种情况。现代数据库可以处理5000万条记录，甚至不会出汗。这是daatbase术语中的一个小表。
答案 2 :(得分：0)
如您所描述的那样使用两个表格应该可以。数据库应该能够处理数百万条记录。
要注意的重点：
1-尽可能优化您的查询。
2-创建适当的索引以加快查询速度。
3-如果您有并发读取/更新操作，请使用InnoDB，因为它支持行级锁定而不是MyISAM。
4-提供良好的硬件来支持数据库服务器。
5-如果价格合理，请在专用服务器上运行数据库服务器。