Storing hashed ID in DB and fetching it or creating hashed ID in code itself and use it?

问题

I have two way of doing handling hashed IDs but need your opinions on which one would better over another and why? I'm only interested in the logic rather than what technology I used for hashing or table data type etc!

I'm going to generate an URL to handle deleting a product and the URL will be like this (last segment is hashed (SHA1) product.id):

...../delete/product/123c45c789ds654dedkjfghr87frd

SCENARIO 1: Store hashed ID in table and use it like this:

> Query:

DELETE ...... WHERE hash_id = '$url_hash_id'

> Table:

products
id - INT
hash_id - VARCHAR(40)

SCENARIO 2: Do not store hashed ID in table but generate it everytime when you create the URL and use it like this:

> Query:

DELETE ...... WHERE SHA1(id) = '$url_hash_id'

> Table:

products
id - INT

What I can think of are:

1. Scenario 1 - Table gets bigger (potentially whole DB because I might end up implement same column for all the tables) but hashing process is run once.
2. Scenario 2 - Less table space used but mySql SHA1() function and php SHA1() functions are called everytime we need it.

回答1:

I'd go with scenario 1 simply because WHERE SHA1(id) = '$url_hash_id' will not use the mysql index. With a large number of records the table scanning will kill you more than the extra overhead of storing the hash_id and an index for that column.

来源：https://stackoverflow.com/questions/25088619/storing-hashed-id-in-db-and-fetching-it-or-creating-hashed-id-in-code-itself-and