Good evening everyone, I want to know the best way to generate unique user ID even when number of registered users are more than two million.
The current way am using to achieve this is by initiating an ID i.e 2083928937 for instance, then checking Database if this ID exists. If it does, then I will increment it by 1 then make a search again for the incremented value until no match is found and the unfound ID will be used.
But am having the feeling that this will cause database issue or even slow down the site as the code have to iterate several times when the site start to have more users.
I do it this way, in which I generate order numbers, where I have a sequence table.
In MongoDB, it can generate a unique Id, based on the server, date and time which is pretty cool.
In the past, I used SQL servers Unique ID with auto increments, but that backfired on me several times.
I forget, but auto increment forgot the last number it was on and added a 1000 to the next number.
I suppose if there was a GUID generator app that worked like Mongo's ObjectId, I would move towards that.
If it ain't broke don't fix it
Discover my world at jkirkerx.com
Sorry, but I downvoted this - for a number of reasons:
* It requires an additional two physical i/o calls - to get the latest value, and to update it afterwards
* It requires that you have a READ lock on the sequence table; to avoid duplicates, you must read the value, insert the new record, and update it all within a transaction and without allowing any other process to read the value. At best this requires an additional lock, but at worst - if poorly coded - can leave that lock in place for a prolonged period and cause a major performance bottleneck
* It creates sequential user ids; presumably you have secure password / two-factor authentication, but by using sequential numeric ids you're making it very easy for hackers as they can just generate sequential hacks on the id
If sequential IDs isn't an issue (and it may not be in all cases) the simplest thing is to use an auto-increment field and return the new ID from the insert statement. Any decent DBMS will keep track without issue. In the event of a transaction rollback there may be a "missing" ID but that shouldn't (be allowed) to cause your application a problem.
A method I use when generating IDs is to use a GUID value (or sometimes a truncated portion of a GUID) and simply INSERT into the table. With a unique key on the ID, then in the vanishingly small likelihood of a duplicate, the INSERT will fail. Catch the "duplicate record" exception, replace the ID with a new GUID and insert again. The performance hit from that is miniscule as it will probably never ever happen.
Server Error in'/' Application.
Description: An exception occurred while processing your request. Additionally, another exception occurred while executing the custom error page for the first exception. The request has been terminated.
I spent all day on this. It just started happening recently.
So I package a model in Angular, and create a body of JSON using JSON.stringify(model)
Then package it all up and send it as a promise. I just noticed that the JSON quotes are escaped out with a slash, and it crashes the API. If I take the slashes out, the API accepts the JSON.
I'm not sure what to make of this, and if I should fix the client side or work on the server side with this.
I put the replace(/\/g, "") in below to test the theory that it's the slashes crashing the API. Now the API works, but I can't see this as a permanent fix.
Sending this data to the API, normally it just sends raw, but I wrote a special service to handle Google SignIn and Googles gapi and gapi.auth2. I can't see how this special API" would encode the JSON.
Your spot on!
That was the issue. Double stringify.
But after thinking about it last night, and realizing the double stringify, I think I'll keep the replace function. So I put it back to my example. After testing without, seems to be more reliable with it. Weird, I create the model before I send the post. And I'm leaving the .Net side as is.
Erreur du serveur dans l'application '/'.
Opération non valide. La connexion est fermée.
Description : Une exception non gérée s'est produite au moment de l'exécution de la requête Web actuelle. Contrôlez la trace de la pile pour plus d'informations sur l'erreur et son origine dans le code.
Détails de l'exception: System.InvalidOperationException: Opération non valide. La connexion est fermée.
Une exception non gérée s'est produite lors de l'exécution de la requête Web actuelle. Les informations relatives à l'origine et l'emplacement de l'exception peuvent être identifiées en utilisant la trace de la pile d'exception ci-dessous.
Trace de la pile:
[InvalidOperationException: Opération non valide. La connexion est fermée.]
Except ... The first bit of code doesn't call the second:
public DataSet GetLs(string que)
public JsonResult LstDepartement()
DataSet ds2 =Dt.GetLsts ("select * from Departement");
GetLs and GetLsts are not the same method ...
And to be honest, doing SQL that way is a very poor idea.
The trouble is that it's prone to SQL Injection. Suppose you want to get departments that all use the same SalesCode - that's easy, add a WHERE clause that specifies the code:
DataSet ds2 =Dt.GetLsts ("SELECT * FROM Departement WHERE SalesCode = " + salescCode);
But ... that's really dangerous!
Never concatenate strings to build a SQL command. It leaves you wide open to accidental or deliberate SQL Injection attack which can destroy your entire database. Always use Parameterized queries instead.
When you concatenate strings, you cause problems because SQL receives commands like:
SELECT * FROM MyTable WHERE StreetAddress = 'Baker's Wood'
The quote the user added terminates the string as far as SQL is concerned and you get problems. But it could be worse. If I come along and type this instead: "x';DROP TABLE MyTable;--" Then SQL receives a very different command:
SELECT * FROM MyTable WHERE StreetAddress = 'x';DROPTABLE MyTable;--'
Which SQL sees as three separate commands:
SELECT * FROM MyTable WHERE StreetAddress = 'x';
A perfectly valid SELECT
A perfectly valid "delete the table" command
And everything else is a comment.
So it does: selects any matching rows, deletes the table from the DB, and ignores anything else.
So ALWAYS use parameterized queries! Or be prepared to restore your DB from backup frequently. You do take backups regularly, don't you?
And your system has no way to add parameters to a command, because you don't create the command until you have built the command string!
I'd strongly suggest you scrap that code and "do it properly" instead.
"I have no idea what I did, but I'm taking full credit for it." - ThisOldTony
AntiTwitter: @DalekDave is now a follower!
Last Visit: 31-Dec-99 19:00 Last Update: 1-Feb-23 7:09