每个用户无限项的MySQL数据库结构

Question

I have a MySQL database with a growing number of users and each user has a list of items they want and of items they have - and each user has a specific ID

The current database was created some time ago and it currently has each users with a specific row in a WANT or HAVE table with 50 columns per row with the user id as the primary key and each item WANT or HAVE has a specific id number.

this currently limits the addition of 50 items per user and greatly complicates searches and other functions with the databases

When redoing the database - would it be viable to instead simply create a 2 column WANT and HAVE table with each row having the user ID and the Item ID. That way there is no 'theoretical' limit to items per user.

Each time a member loads the profile page - a list of their want and have items will then be compiled using a simple SELECT WHERE ID = ##### statement from the have or want table

Furthermore i would need to make comparisons of user to user item lists, most common items, user with most items, complete user searches for items that one user wants and the other user has... - blah blah

The amount of users will range from 5000 - 20000

and each user averages about 15 - 20 items

will this be a viable MySQL structure or do i have to rethink my strategy?

Thanks alot for your help!

Answer 1

This will certainly be a viable structure in mysql. It can handle very large amounts of data. When you build it though, make sure that you put proper indexes on the user/item IDs so that the queries will return nice and quick.

This is called a one to many relationship in database terms.

Table1 holds:
 userName | ID

Table2 holds:
userID | ItemID

You simply put as many rows into the second table as you want.

In your case, I would probably structure the tables as this:

users
id | userName | otherFieldsAsNeeded

items
userID | itemID | needWantID

This way, you can either have a simple lookup for needWantID - for example 1 for Need, 2 for Want. But later down the track, you can add 3 for wishlist for example.

Edit: just make sure that you aren't storing your item information in table items just store the user relationship to the item. Have all the item information in a table (itemDetails for example) which holds your descriptions, prices and whatever else you want.

Answer 2

I would recommend 2 tables, a Wants table and a Have table. Each table would have a user_id and product_id. I think this is the most normalized and gives you "unlimited" items per user.

Or, you could have one table with a user_id, product_id, and type ('WANT' or 'HAVE'). I would probably go with option 1.

Answer 3

What you're theorizing is a very legitimate database structure. For a many to many relationship (which is what you want), the only way I've seen this done is to, like you say, have a relationships table with user_id and item_it as the columns. You could expand on it, but that's the basic idea.

This design is much more flexible and allows for the infinite items per user that you want.

In order to handle wants and have, you could create two tables or you could just use one and have a third column which would hold just one byte, indicating whether the user/item match is a want or a need. Depending on the specifics of your projects, either would be a viable option.

So, what you would end up with is at least the following tables:

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

Hope that helps!

Answer 4

As you mentioned in your question, yes, it would make much more sense to have a separate tables for WANTs and HAVEs. These tables could have an Id column which would relate the row to the user, and a column that actually dictates what the WANT or HAVE item is. This method would allow for much more room to expand.

It should be noted that if you have a lot of of these rows, you may need to increase the capacity of your server in order to maintain quick queries. If you have millions of rows, they will have a great deal of strain on the server (depending on your setup).