Mysql插入多个唯一行

Question

Wondering if this procedure can be accomplish without having any data error. Using PHP7 and MySQL innoDB. This is still in theory stage and if you can give good input and recommendation before the project starts would be a tremendous help.

The case will be that there will be multiple transactions and there could be multiple transactions happening at the same time even in microseconds. The transaction table will have a hashed column where the value of hash is the hashed of all the information of that transaction + salt + the previous hash value entry (if exist).

The process will be:

1. PHP will receive transaction order (user info, amount and etc)
2. PHP get the value of the previous transaction hash (if exist)
3. If there is no transaction exist (first transaction), PHP will hash the entire transaction information (sha256), Hx0 and MySQL will create it's first entry with the hash value of Hx0
4. If there is already a transaction before, PHP will take the previous hash value (Hx0) and hash it along with the entire current transaction info (sha256), Hx1{Hx0} and MySQL will create the new entry in the database
5. This process repeats all the way between PHP and MySQL, Hxn+1{Hxn}

My concern is, if there could be a possibility of several transaction using the same hash value of the previous transaction if those transaction occurs at the same time?

For example, latest Tx hashed value is abcd. If 5 new transaction goes in at the same time in microsecond, will those 5 use that same latest Tx hashed value abcd? The result i'm trying to achieve is that it will be in order and use the latest hashed value properly.

[edited] Let me try to explain more clearly.

1. First transaction will have the value of hash hash(info + timestamp) = "acbd"
2. Second transaction will have the value of hash(info + timestamp + "abcd") = "cdfg"
3. Third transaction will have the value of hash(info + timestamp + "cdfg") = "hijk"

My concern is that if 3 transactions enter at the same time in microseconds or nanoseconds after that third transaction, will the new 3 transactions be like as follows? (fourth transaction is still hashing with the previous hash, while the fifth transaction and sixth transaction is also hashing using the same previous hash, before fourth transaction even manage to complete and update to database) :

1. Fourth transaction hash(info + timestamp + "hijk") = "12sd"
2. Fifth transaction hash(info + timestamp + "hijk") = "x3sd"
3. Sixth transaction hash(info + timestamp + "hijk") = "n76h"

I would expect and hope that my results to be:

1. Fourth transaction hash(info + timestamp + "hijk") = "12sd"
2. Fifth transaction hash(info + timestamp + "12sd") = "mn34"
3. Sixth transaction hash(info + timestamp + "mn34") = "09lk"

Plan B is (what do you think?):

1. Create two tables. One (table A) to receive all transaction without hashing, and another (table B) to hash each transaction in table A one by one.
2. Table A will insert all entries regardless if it's in nano second simultaneously.
3. Table B will just happily go through Table A and hash each entry one by one which also not affected by the simultaneous transactions and having the hash value properly in order.

Answer 1

Depends on what your hashing function uses as argument. Let me teach you a mathematical beauty behind hashing functions:

No collision and robustness

Hash functions are meant to not create collisions and to be robust.

• What is a collision? Consider f as hashing function and x and y two different strings. A collision would happen if there would exist two different strings x and y such that f(x) = f(y). Obviously this is very not good. Therefore hashing functions are designed so that they create no collisions.
• What is robustness? Unlike in previous case, let now x and y be two equal strings. We want the hashing function to return same value no matter when we run it on same string, therefore a hashing function is robust, if for x = y, it is also f(x) = f(y).

Now that we know that, we must ask ourselves what we want to pass to hashing function. Obviously something that is distinct from user to user, e.g. password, username, e-mail, a combination of those. Also we can add something to it, a salt, like date, just to make it more complex but there is really no necessity.

Your case

So basically what you want to worry about is only what data are you going to be hashing, which is username, amount, etc. Since the PHP script will run separately for each transaction and since data you will be hashing will be different (amount, time, etc. might be the same, but username will be different), there is no need to worry about collision.