Login

It also depends on what you care about for your application. For n-tier apps GUIDs/UUIDs are simpler to implement and are easier to port between different databases. To produce Integer keys some database support a sequence object natively and some require custom construction of a sequence table.

Integer keys probably (I don't have numbers) provide an advantage for query and indexing performance as well as space usage. Direct DB querying is also much easier using numeric keys, less copy/paste as they are easier to remember.

As long as you use a DB system with efficient storage, HDD is cheap these days anyway...

I know GUID's can be a b*tch to work with some times and come with some query overhead however from a security perspective they are a savior.

Thinking security by obscurity they fit well when forming obscure URI's and building normalised DB's with Table, Record and Column defined security you cant go wrong with GUID's, try doing that with integer based id's.

Why couple your primary key with your URI?

Why not have your URI key be human readable (or unguessable, depending on your needs), and your primary index integer based, that way you get the best of both worlds. A lot of blog software does that, where the exposed id of the entry is identified by a 'slug', and the numeric id is hidden away inside of the system.

The added benefit here is that you now have a really nice URL structure, which is good for SEO. Obviously for a transaction this is not a good thing, but for something like stackoverflow, it is important (see URL up top...). Getting uniqueness isn't that difficult. If you are really concerned, store a hash of the slug inside a table somewhere, and do a lookup before insertion.

**edit:** Stackoverflow doesn't quite use the system I describe, see Guy's comment below.

I think using a GUID would be the better choice in your situation. It takes up more space but it's more secure.

[1]:http://teddziuba.com/2008/07/practical-unique-identifiers.html
[2]:https://stackoverflow.com/users/104/ted-dziuba

I've tried both in real web apps.

My opinion is that it is preferable to use integers and have short, comprehensible URLs.

As a developer, it feels a little bit awful seeing sequential integers and knowing that some information about total record count is leaking out, but honestly - most people probably don't care, and that information has never really been critical to my businesses.

Having long ugly UUID URLs seems to me like much more of a turn off to normal users.

YouTube uses 11 characters with base64 encoding which offers 11^64 possibilities, and they are usually pretty manageable to write. I wonder if that would offer better performance than a full on UUID. UUID converted to base 64 would be double the size I believe.

More information can be found here:

# Pros and Cons of UUID

> Note: [uuid_v7][1] is time based uuid instead of random. So you can
> use it to order by creation date and solve [some performance issues
> with db inserts][2] if you do really many of them.

**Pros**:
- can be generated on api level (good for distributed systems)
- hides count information about entity
- doesn't have limit 2,147,483,647 as 32-bit int
- removes layer of errors related to passing one entity id `userId: 25` to get another `bookId: 25` accidently
- more friendly graphql usage as `ID` key

**Cons**:
- 128-bit instead 32-bit int (slightly bigger size in db and ~40% bigger index, around ~30MB for 1 million rows), should be a minor concern
- can't be sorted by creation (**can be solved with uuid_v7**)
- [non-time-ordered UUID versions such as UUIDv4 have poor database index locality][3] (**can be solved with uuid_v7**)

---

# URL usage

Depending on app you may care or not care about url. If you don't care, just use `uuid` as is, it's fine.

If you care, then you will need to decide on url format.

Best case scenario is a use of unique slug if you ok with never changing it:
```