Query and locate data after table sharding

I split the "Product table" into tables based on the user ID. When I view the product details page, the url link must have a user ID + product ID to locate the table where the product is located, and then read the information. I don't want to include two parameters in the url. I want to combine the user ID and product ID into a parameter...

I split the "Product table" into tables based on the user ID. When I view the product details page, the url link must have a user ID + product ID to locate the table where the product is located, and then read the information.

I don't want to include two parameters in the url. I want to combine the user ID and product ID into one parameter (or try other parameters ), therefore, an algorithm is required to process the user ID + product ID, but you do not know how to do this.

Reply content:

I split the "Product table" into tables based on the user ID. When I view the product details page, the url link must have a user ID + product ID to locate the table where the product is located, and then read the information.

I don't want to include two parameters in the url. I want to combine the user ID and product ID into one parameter (or try other parameters ), therefore, an algorithm is required to process the user ID + product ID, but you do not know how to do this.

User id 12, product id 1200, final id is 12B1200, B is belong meaning, no matter, just separate
What algorithms do you need? I really don't think it's easy to get rid of it. If you don't want to be tall, you just need to use what 16, 18, 20, 50, and so on, and then link it to the code. People who want to read the code will feel better at nb.

Cache and find the corresponding data

Simply make it into a json format. http: // url /? Id = {'uid': 12, 'pid ': 1200}. It is convenient to process the background.

Or you can just try it out. All the parameters are encapsulated in json.
Http: // url /? Par = {'A': 'XX', 'B': 'xx '......}

Dizzy, come back to edit the third time, really want to stop
Another solution is to create a table to specifically record the items published by a user, so that the details page only needs to load the item ID, then, use the product ID to associate the user ID in the table, and then splice the database name to find the product details.
Of course, there is a premise that the product ID is unique