How is the ID of CSDN generated?

A CSDN is generated when a third-party login is used id:u012365644

How is this ID generated? Is it absolutely the only thing?

Reply to discussion (solution)

You can consider the automatic growth of IDs in the database.

Theoretically absolutely unique, the generated method should be self-increment (this numbering rule is usually defined by itself)

You can consider the automatic growth of IDs in the database.

Oh, actually I thought so too!

The user table has a field account, and the field is unique!
When a third-party account is logged in, it will register to generate a random account substr (' U '. $uid. Uniqid (rand ()), 0,10), but how is this $uid obtained?

You can consider the automatic growth of IDs in the database.

Oh, actually I thought so too!

The user table has a field account, and the field is unique!
When a third-party account is logged in, it will register to generate a random account substr (' U '. $uid. Uniqid (rand ()), 0,10), but how is this $uid obtained?

Third-party login, the first time, there will be stored in the local Information bar, this time to join a user record entry

You can consider the automatic growth of IDs in the database.

Oh, actually I thought so too!

The user table has a field account, and the field is unique!
When a third-party account is logged in, it will register to generate a random account substr (' U '. $uid. Uniqid (rand ()), 0,10), but how is this $uid obtained?

Third-party login, the first time, there will be stored in the local Information bar, this time to join a user record entry

I was like this:
1, a user table, a user_platform third-party account binding table
2, the User_platform table has ID (self-increment), UID (corresponding to the user UID in Users table), type (third party logo such as QQ), OpenID (third party return unique ID)
3, when the third-party account first login, the first will create an account in the user table, the account creation is successful, only in the User_platform table, write the binding record, that is, record the newly created user uid and OpenID

In order, so when creating a new user account, I need to get uid! first This is my idea, how do you do it, the first time to get a third-party login?

The first time I did this, I didn't know it was right.

I mean, bad ID's not going to change.

Theoretically absolutely unique, the generated method should be self-increment (this numbering rule is usually defined by itself)
I was like this:
1, a user table, a user_platform third-party account binding table
2, the User_platform table has ID (self-increment), UID (corresponding to the user UID in Users table), type (third party logo such as QQ), OpenID (third party return unique ID)
3, when the third-party account first login, the first will create an account in the user table, the account creation is successful, only in the User_platform table, write the binding record, that is, record the newly created user uid and OpenID

Due to sequencing, I need to get uid! when creating a new user account This is my way of thinking, how do you do it, I first get third party login

MySQL has an auto-growing field that guarantees uniqueness

Should be an auto-grow function instead of an identity column

MySQL has an auto-growing field that guarantees uniqueness
But when inserting data, how do you know the self-increment uid first?

MySQL has an auto-growing field that guarantees uniqueness
But when inserting data, how do you know the self-increment uid first?
Insert data successfully, return the current self-increment ID.

MySQL has an auto-growing field that guarantees uniqueness
But when inserting data, how do you know the self-increment uid first?
Insert data successfully, return the current self-increment ID.

If the data is inserted successfully, no ID is needed! When inserting a record, how do you guarantee that the generated Account field is unique (where the UID is increased)?

Because the UID is self-increasing, I want to make sure the generated account is unique by uid+ string.

If you can't get the self-increment uid, you can only write one more UPDATE statement!

Will not be self-increasing, because CSDN certainly do the user's sub-library, so that there will be similar UID in multiple libraries, his UID should be random, but this random is more complex

Will not be self-increasing, because CSDN certainly do the user's sub-library, so that there will be similar UID in multiple libraries, his UID should be random, but this random is more complex

Oh, tks.

