数据库中的很多记录
问题描述：
我正在计划一个项目站点，我将有大约1万个用户。在服务中将有大约5千个静态产品存储在一个表中。每个用户将拥有至少1千个产品（最多5千个）。现在我有一个问题：如何设计一个关系模型？当然用户表是可以的。数据库中的很多记录
我会保留：10,000（用户）* 1,000（产品）= 10,000,000条记录。 我有一个想法：创建（例如）100个表，并将用户的每个产品分配给一个表。 用户每天更新大约50条记录。
我想使用symfony 1.4，doctrine 1.x和MySQL/PostgreSQL。这是个好主意？
答
100个表的定义相同吗？对不起，但这是一个可怕的想法。现在的数据库能够处理数百万行表。
答
我不知道框架，但MySQL或PostgreSQL应该能够处理它没有问题。但是，我建议不要为每个用户分配一个表，除非您允许用户直接访问数据库（即：不通过只配置了要显示的特定输出的网页），并为其分配自己的连接凭据他们无法查看其他用户的产品信息。
我认为对于MySQL来说，至少有一个更好的主意是创建一些InnoDB表，并将他们的搜索/编辑结果限制为符合其当前登录ID的用户ID记录。拥有一堆额外的表将会浪费很多空间（IIRC，每个InnoDB表的最小大小为10 MB所需的空间使用量），并且您的应用程序最终将受到64TB最大限制，仅限于您将创建个人用户表。
是的。使用一个好的标准关系模型，如果你有扩展问题，他们可以通过集群或分片来处理，或者DBA喜欢扔掉的其他单词之一。 – glomad 2011-02-28 23:18:48
那么你认为从1000万条记录的数据库中选择一个用户的所有产品的时间，将会比从数据库中选择记录的时间少100倍？ – NHG 2011-02-28 23:43:57
如果你看看b树，你会发现是的，如果索引正确，它不会花费太多时间。 – 2011-03-01 00:06:17