针对每个用户的大数据进行数据库设计的最佳方法是什么？

Question

I got a job to make a restaurant "survey" web app that will just track users status regarding to the restaurant (will be explained later) and if that restaurant is your favorite. Pretty much that's all the data I have and need. I also have categories and subcategories but they aren't that much used.

So we are talking about 386 restaurants in total (with an option to add more). After a sign-up every user can fill out the data and then save it for later use on the application. User can set one of the three status options (0 - never been there,1 - planning to go soon, 2 - went there) and they can also add to their favorites.

My current solution is this:

• I keep only record of those with status 1 and 2, 0 is ignored and not stored in DB
• Also if someone changes status from 2 or 1 to 0 the record gets deleted
• I keep the full JSON data of the restaurants in the local storage, then when the user logs in, server fetches all of his data (let's say 20 records) and then the data gets merged by ID with the static local storage list
• So at the end, that static JSON list gets transformed in a way that records that were found in the database are added to the object on a new property that is called record. Those that don't have a record have a empty record property added.

So finally my question would be is this the right/optimal way of doing it. At first I had an idea to initialize all of the 368 restaurants for every user that registers and then access them by index, because that way I would know that ID 0-367 is user 1, ID 367 - 735 is user two etc. But as you can see for only 10 users there are 3k+ records that will probably stay empty/null.

On the other hand my goal with this current implementation was to divide the work on frontend and backend because the restaurant data is static but I'm concerned when/if the records count reaches lets say million/10 million. In that case all of the records would be scattered around and someone could have a record on ID 4 and then on ID 904,302.

Here is the current table that I use:

I should note that I made index on every page and tried to optimize it as much as possible.

Answer 1

This doesn't sound like a lot of data.

Just keep each status record for each user and each restaurant. The timing of the status change is probably much more important than you realize. There might be other information that you want as well. Perhaps someone who has never been to a restaurant has heard something about it and you want to include that.

Then, summarize the data as you need from the transactions.

This is flexible for adding restaurants and adding users. If you end up with zillions of restaurants and zillions of users, you can think about how to optimize any reporting that you want done. In the meantime, indexes on a per-restaurant and per-user basis are probably sufficient.