3

我有一个用户越来越多的 MySQL 数据库，每个用户都有一个他们想要的项目和他们拥有的项目的列表 - 每个用户都有一个特定的 ID

当前数据库是前一段时间创建的，当前每个用户在 WANT 或 HAVE 表中都有一个特定的行，每行 50 列，用户 ID 作为主键，每个项目 WANT 或 HAVE 都有一个特定的 ID 号。

这目前限制了每个用户添加 50 个项目，并使数据库的搜索和其他功能大大复杂化

重做数据库时 - 是否可以简单地创建一个 2 列 WANT 和 HAVE 表，每行都有用户 ID 和项目 ID。这样，每个用户的项目就没有“理论”限制。

每次成员加载个人资料页面时 - 然后将使用来自 have 或 want 表的简单 SELECT WHERE ID = ##### 语句编译他们想要和拥有的项目列表

此外，我需要比较用户与用户的项目列表、最常见的项目、拥有最多项目的用户、完整的用户搜索一个用户想要而另一个用户拥有的项目...... - 等等等等

用户数量范围为 5000 - 20000

每个用户平均大约 15 - 20 个项目

这将是一个可行的 MySQL 结构还是我必须重新考虑我的策略？

非常感谢你的帮助！

4

4 回答 4

4

这在 mysql 中肯定是一个可行的结构。它可以处理非常大量的数据。但是，当您构建它时，请确保在用户/项目 ID 上放置正确的索引，以便查询能够快速返回。

这在数据库术语中称为一对多关系。

Table1 holds:
 userName | ID

Table2 holds:
userID | ItemID

您只需将任意多的行放入第二个表中即可。

在你的情况下，我可能会这样构建表格：

users
id | userName | otherFieldsAsNeeded

items
userID | itemID | needWantID

这样，您可以简单地查找 needWantID - 例如 1 表示需要，2 表示需要。但稍后，您可以为愿望清单添加 3。

编辑：只需确保您没有将项目信息存储在表中items，只需存储用户与项目的关系即可。将所有项目信息放在一个表格中（例如 itemDetails），其中包含您的描述、价格和您想要的任何其他内容。

于 2012-07-24T23:38:08.740 回答
1

我会推荐 2 张桌子，一张 Wants 桌子和一张 Have 桌子。每个表都有一个 user_id 和 product_id。我认为这是最规范的，并为每个用户提供“无限”项目。

或者，您可以有一个带有 user_id、product_id 和类型（'WANT' 或 'HAVE'）的表。我可能会选择选项1。

于 2012-07-24T23:39:13.313 回答
1

你的理论是一个非常合法的数据库结构。对于一个many to many关系（这是你想要的），我看到这样做的唯一方法是，就像你说的那样，有一个以 user_id 和 item_it 作为列的关系表。您可以对其进行扩展，但这是基本思想。

这种设计更加灵活，并且允许每个用户拥有您想要的无限项。

为了处理需求和拥有，您可以创建两个表，或者您可以只使用一个表并使用第三列，该列仅包含一个字节，指示用户/项目匹配是需要还是需要。根据您项目的具体情况，任何一个都是可行的选择。

因此，您最终会得到至少以下表格：

Table: users
Cols:
  user_id
  any other user info

Table: relationships
Cols:
  user_id
  item_id
  type (1 byte/boolean)

Table: items
Cols:
  item_id
  any other item info

希望有帮助！

于 2012-07-24T23:40:11.453 回答
1

正如您在问题中提到的那样，是的，为 WANT 和 HAVE 分别设置一个表格会更有意义。这些表可能有一个将行与用户相关联的 Id 列，以及一个实际指示 WANT 或 HAVE 项是什么的列。这种方法将允许更多的扩展空间。

应该注意的是，如果您有很多这样的行，您可能需要增加服务器的容量以保持快速查询。如果您有数百万行，它们将对服务器造成很大的压力（取决于您的设置）。

于 2012-07-24T23:40:45.430 回答