我有一个拥有越来越多用户的MySQL数据库,每个用户都有他们想要的项目列表和他们拥有的项目 - 每个用户都有一个特定的ID
当前数据库是在不久前创建的,它当前每个用户在WANT或HAVE表中都有一个特定的行,每行有50列,用户ID为主键,每个项目WANT或HAVE都有一个特定的id号。
这目前限制每个用户增加50个项目,并使数据库的搜索和其他功能大大复杂化
重做数据库时 - 只需创建一个2列WANT和HAVE表,每行包含用户ID和项ID,是否可行。这样,每个用户的项目就没有“理论上的”限制。
每次成员加载配置文件页面时,都会使用来自has或want表的简单SELECT WHERE ID = #####语句编译他们想要和有项目的列表
此外,我需要将用户与用户项目列表,大多数常见项目,具有大多数项目的用户,完全用户搜索一个用户想要的项目以及另一个用户拥有的项目进行比较... - 等等等等等等。
用户数量范围为5000 - 20000
每个用户平均约15-20个项目
这是一个可行的MySQL结构还是我必须重新考虑我的策略?
非常感谢你的帮助!
答案 0 :(得分:3)
这肯定是mysql中一个可行的结构。它可以处理非常大量的数据。当你构建它时,请确保在用户/项目ID上放置适当的索引,以便查询返回良好和快速。
这在数据库术语中称为一对多关系。
Table1 holds:
userName | ID
Table2 holds:
userID | ItemID
您可以根据需要在第二个表中添加尽可能多的行。
在你的情况下,我可能会将表格结构如下:
users
id | userName | otherFieldsAsNeeded
items
userID | itemID | needWantID
这样,您可以对needWantID进行简单查找 - 例如1表示Need,2表示Want。但是稍后在赛道上,您可以为愿望清单添加3个。例如。
编辑:只需确保您没有将项目信息存储在表格items
中,只需将用户关系存储在项目中即可。将所有项目信息放在一个表格中(例如itemDetails),其中包含您的描述,价格和您想要的任何其他内容。
答案 1 :(得分:1)
我会推荐2个表,一个Wants表和一个Have表。每个表都有一个user_id和product_id。我认为这是最正常化的,并为每个用户提供“无限”项目。
或者,您可以拥有一个包含user_id,product_id和type('WANT'或'HAVE')的表。我可能会选择1。
答案 2 :(得分: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
希望有所帮助!
答案 3 :(得分:1)
正如你在问题中提到的,是的,为WANT和HAVE设置一个单独的表会更有意义。这些表可以有一个Id列,它将行与用户相关联,以及一个实际指示WANT或HAVE项目的列。这种方法可以提供更大的扩展空间。
应该注意的是,如果您拥有大量这些行,则可能需要增加服务器的容量以保持快速查询。如果你有数百万行,他们将在服务器上承受很大的压力(取决于你的设置)。