在数据库中存储整数数组

Question

我正在创建一个将存储 100.000（未来可能更多）用户的数据库。虽然这显然发生在每个用户有 1 行的表中，但每个用户都可以（并且将）存储数百个项目。在编程语言中，这意味着用户有 2 个整数数组（或一个二维数组）：一列是 itemid，一列是金额。

我的直觉告诉我要创建一个表格来保存所有这些项目，其中包含（用户 ID、项目 ID、金额）之类的行。然而，这将导致一个巨大的表。 200.000 个用户，每个用户有 250 个项目……也就是说一张表中有 5000 万个条目。这一点，再加上桌子将持续快速变化的事实，让我感到害怕。 （有多快？我估计每秒最多 100 次修改。）

通常会有 100 到 2000 个用户，所有用户都添加和删除项目，以及修改数量。这些动作可以并且将会在编程代码中发生。如下：

• 用户启动会话，程序从数据库中加载所有用户项
• 用户修改项目列表
• 每隔几分钟，更改就会保存到数据库中
• 当用户结束会话时，它也被保存到数据库中

值得注意的是，用户可以存储的物品数量是有上限的。

除了使用单独的表格之外，还有其他选择吗？也许将值保存在格式化的文本字符串中？或者这是使用 MySQL 数据库实际上是一个 Bad Idea™ 的实例之一？

感谢您的宝贵时间和见解。

Answer 1

我的直觉告诉我要创建一张桌子来存放所有这些物品

你的直觉是对的。

1) 避免过早优化

2) 不要违反规范化规则，除非你有非常好的和真正的理由这样做

3）为什么你怀疑多表的方法会更快？

一张表中有 5000 万个条目

那又怎样？即使您只有用户 ID 上的索引，与每个用户单个表相比，性能差异也不会明显变慢（实际上，如果有 200,000 个用户，它会快得多 - 因为 DBMS 可以轻松地保持打开状态）每个表的文件句柄！）。

我估计每秒最多 100 次修改

应该可以使用 MySQL 和相当基本的硬件，但如果是我，并且我想要一点空间，我会使用一对镜像 SATA 磁盘，一个镜像上的表，另一个镜像上的索引。

我要关心的唯一问题（无论您选择的 2 个模型中的哪一个都适用）是支持 2000 个并发连接。连接必须是并发的吗？或者每个用户可以下载一个工作集（可选地使用乐观锁定策略）并关闭连接，然后在新连接上推回更改？如果没有，那么您可能需要大量内存和 CPU。

但是暂且不说是使用一张大表还是使用许多小表，如果这是数据的唯一用途，并且对特定数据项的访问不是并发的，那么为什么还要使用关系数据库呢？ NoSQL 或共享文件系统也可以正常工作。

Answer 2

将数据作为数组放入一个字段几乎总是一个错误。它使查询数据变得更加困难和耗时，并且不太可能使用索引。没关系，如果值只是文本，您永远不需要为数组找到一个或多个元素，但根据我的经验，这种情况很少遇到。现代数据库可以毫不费力地处理 5000 万条记录。那是数据库术语中的一个小表。

Answer 3

按照您使用两个表的描述进行操作应该没问题。数据库应该能够处理数百万条记录。

看的重点：

1- 尽可能优化您的查询。

2- 创建适当的索引以加快查询速度。

3- 如果您有并发读取/更新操作，请使用 InnoDB，因为它支持行级锁定，而不是 MyISAM。

4- 提供良好的硬件来支持数据库服务器。

5- 如果负担得起的话，在专用服务器上运行数据库服务器。