This question already has answers here:
Use email address as primary key?
(25 answers)
Closed 7 years ago.
I am making an application in which users may create their accounts. I make user email as primary key in user's table. Is this technique is really bad technique? Should I create auto increment integer as primary key?
Yes, it is a terrible idea. An email is something long (so your key is longer than necessary), and it isn't immutable. I've changed at least three emails in the last ten years (providers closed).
Related
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 3 years ago.
Improve this question
I am working on a project for college and stumbled upon a problem which I am not sure how to handle it in a best way.
I have a SQL Server database that is manually created, and a Winforms project in Visual Studio written in C#. The application should do CRUD operations on database.
My question is what is the best way for manipulate the primary key columns in the tables? Should I define them in database as auto increment integer and let the database management system to handle the primary keys or should I define them just as int and populate them programatically within Visual Studio project, and if so how to do it?
I am not looking for complete solution, just for hint what is the best way of doing this.
I am very much a beginner, so please be gentle...
In general, auto-incremented (or identity or serial) primary keys are the way to go. You don't generally want your application to be worrying about things like whether the values have been used already.
If your application is multi-threaded -- that is, multiple users at the same time -- then the database will take care of any conflicts. That is quite convenient.
I am a fan of surrogate keys created by the database. In databases that cluster (sort) the rows by the primary key, it is much more efficient to have an automatically incremented value. And the database can take care of that.
There are some cases where you want a natural key. Of course, that is also permissible. But if you are going to invent a primary key for a table, let the database do the work.
When defining structures for DB backing for CRUD operations, you need to ask yourself:
Does it matter that my primary key is highly predictable?
By that I mean, if I am launching a user to a screen such "whatever.com/something/edit/1"
Aside from obvious security, does it help or harm the business process that a user can manipulate the url and inject 2 or 3 or 4 into path?
If it doesn't matter then absolutely set it as auto increminitng int on the DB side and offload that area of responsibility to the database to handle. You now no longer have to highly concern yourself with dealing with key generation.
IF it does matter then set the primary key as a unique identifier. In code when adding a new record set then you will generate a new GUID and set that as the primary key (Guid.NewGuid()). This would prevent the user from traversing your data in an uncontrolled manner as randomly guessing GUIDs would then be problematic to them. EX:
New path: "whatever.com/something/edit/0f8fad5b-d9cb-469f-a165-70867728950e"
Not saying that it is impossible to stumble upon things but the regular person using your application would not be so inclined to go exploring with url manipulation since they would be wasting 99.99% of their time with invlaid posts trying to guess a valid GUID that is registered in your DB.
As an added comment, if you decided to keep the primary key as a int and not use auto-increment then you are just setting yourself up for a ton of unnecessary work where I have never personally ever seen any real return on investment for the logic you would right to check if the placeholder is already used. That and think about tracking history? You would be settings yourself up for a world of pain if you ever decided to remove records from the table and then reuse them. That is a whole other set of concerns you would have to manage on top of what you are doing.
This question already has answers here:
Identity increment is jumping in SQL Server database
(6 answers)
Closed 6 years ago.
I have a table in EntityFramework that has a field named by ID,
this field is primary key and is Identity.
when i add records into this table, this field value increases per recor, after adding several records, this value suddenly increases
For example, increased from 90 in 1010
While no transaction has been unsuccessful.
what is the problem?
If you are using Azure SQL this can just happen. We had it happen a few times. It is just the nature of how Azure sql works.
See this question Windows Azure SQL Database - Identity Auto increment column skips values it goes into a detailed explanation for a case very similar to yours
This question already has answers here:
Is a GUID unique 100% of the time?
(24 answers)
Are GUID collisions possible?
(19 answers)
Closed 9 years ago.
I generate keys for my software as:
Guid.NewGuid().ToString();
that returns something like: 15c6bd70-8d3c-42d0-bb24-40da6e08ed9d
anyways everytime someone purchases a new software I generate a new key. can it be possible that I generate the same key twice? Everytime someone purchase the software I call the method: Guid.NewGuid().ToString() Should I append a counter at the end of each guid to be 100% sure that there cannot be duplicates?
Edit
A constructor of the Guid class takes a byte array of 16 bytes as a parameter. If you serialize the current date (8 bytes) then append another 8 random bytes to the constructor of the GUID will that be 100% secure? I am just asking for learning based on your answers I will probably just have Guid.NewGuid()
An excerpt from one of the best blog series ever written about the Guid:
There are a number of possible strategies for making a unique GUID, and in fact information about the strategy used is encoded in the first four bits of the third "group"; almost every GUID you see will be of the form {xxxxxxxx-xxxx-1xxx-xxxx-xxxxxxxxxxxx} or {xxxxxxxx-xxxx-4xxx-xxxx-xxxxxxxxxxxx}.
If there is a one in that place then the algorithm used to guarantee uniqueness is essentially a variation on the ISBN strategy. The GUID is guaranteed to be unique "in space" by choosing some of the bits as the MAC address of the network card in the machine. (The tricky problem of ensuring that no two network cards in the world have the same MAC address is solved somehow by someone else; how that problem is solved, we don't particularly care. The cost of solving that problem is passed on to you, the consumer, in the purchase cost of the network card.)
In short, it's very unlikely that they would ever collide.
Yes, it's possible, but extremely unlikely. The probability for a GUID collision is about as likely as a bit in the GUID changing spontaneously in memory, and that kind of thing is not something that you normally worry about.
You can already be 100% sure, that is of course if you dont mean that you need to be 100.000000000000000000000000000000000000% sure.
Just use the Guid.. no need to append anything. Unless you expect to sell more copies than there are atoms in the universe (unlikely).
This question already has answers here:
Why does SignHash need to know what hash algorithm was used?
(2 answers)
Closed 9 years ago.
Since RSACryptoServiceProvider.SignHash signs an already hashed message - why does it need to know which hash algorithm was used?
It seems that in order to make the signature more useful to the recipient, the OID of the hashing algorithm that was used is included in the signature (per PKCS1). That way, it does not have to be communicated separately.
This question already has answers here:
YouTube URL algorithm?
(11 answers)
Closed 3 years ago.
I noticed on YouTube their keys look like this "BwgT06NY1FE". I was just wondering how is this type of key created? Is this based on a GUID?
This is most likely Base36. All letters and numbers. It's pretty common, because you can use a "SERIAL" in a database and just increment it, and then just parse from Base36 in your URL.
It makes for nice URLs (bit.ly also uses this format), but has some drawbacks. Ie, you wouldn't want to use it for any sort of private data because people can just type in a random number and get a result (it's unlikely someone could guess a GUID in use by your database unless they try a few billion)..