Small bets to achieve financial independence

Is it bad practice to choose your own document ID in Firestore or a NoSQL database?

What if you’re left to choose the IDs of your documents on a NoSQL database like Firestore? Will you use a random string for your IDs, or try to use a combination of your document fields?

Let’s take books for example. A good candidate for a unique ID is the ISBN, it’s a book identifier and is supposed to be unique. Until now, using the ISBN as an ID looks promising. But what happens if you start supporting self-published (e)books? Or local books? Or old books with no ISBN? Well… things can be tough!

Whenever you use a document property, like ISBN, book title, etc… as a unique id for your document, you’ll quickly hit some edge cases down the road. This without talking about what happens if you change a property due to a typo for example? Will you go and change the ID everywhere?

All this sounds like you should never use a document property as a unique ID, and it’s true. But what should you use instead? A random string? It may sound strange, but that’s the safest option.

Using long, random strings, make IDs independent from the document itself. This will help you avoid a collision (two documents or more sharing the same ID) and you’ll not need to update the ID if you change something in the document.

How to choose unique IDs?

Well, you can choose a random ID if you want. But if you’re using Firestore, you can let it do the work for you. By default, Firestore can create strong unique IDs for your documents if you don’t force your own IDs. When creating a new document, just insert it directly to the collection of documents. This will automatically create a new ID for it:

// This is how it looks with Firestore for the Web
const res = await db.collection('books').add({
  name: 'The Book Of Good Dogs',
  country: 'Morocco',
  isbn: '123456890',
  price: 0
});

// To get the id of the document
console.log( res.id );

Other examples for other platforms can be found in the official documentation.

If you still want to generate a random ID yourself, you will need to use doc() before:

const randomId = generateSomeRandomId();
const res = await db.collection('books').doc( randomId ).set({
	name: 'The Book Of Good Dogs',
  country: 'Morocco',
  isbn: '123456890',
  price: 0
});

That’s it! Next time you’re tempted to come with a way of creating new IDs for your document, stop what you’re doing, and use random strings.

Do not miss my next post! Drop your email in the box below and get it straight to your inbox:

JOIN MY MAILING LIST

Hey, I’m Ahmed, I write about productivity, business, and achieving financial independence. Get my future posts directly in your email:

2 responses to “Is it bad practice to choose your own document ID in Firestore or a NoSQL database?”

  1. darylchymko Avatar
    darylchymko

    One other interesting thing to look at here might be performance. S3 used to recommend randomized keys to increase performance, I think because it split requests across “shards.” I wonder if this is an issue in Firebase or not?

    (Note as of a few years ago, you no longer need to randomize they key on S3 for performance)
    https://aws.amazon.com/about-aws/whats-new/2018/07/amazon-s3-announces-increased-request-rate-performance/)

    1. Ahmed Avatar
      Ahmed

      Oh didn’t think about this, but it makes sense! Looked around to see if it applies to Firestore, but couldn’t find any information.

Leave a Reply

Discover more from Ahmed

Subscribe now to keep reading and get access to the full archive.

Continue reading