![]() There are a few reasons they chose NanoID for this task, which they outline in their blog post. To populate this column, they’re using NanoIDs. This column was added to any model that was going to be exposed to a client. How the team at PlanetScale went about this was using a BigInt as their primary key and adding a second unique column to their tables called public_id. I started researching different approaches for primary keys and eventually found the PlanetScale article, where they explained their approach when building their schema for their API. This was working great, until it got really cumbersome to maintain. I do, however, try to avoid exposing my integer IDs in my URLs and rely on unique slugs instead. In my projects, I tend to use integers simply because the projects I work aren’t particularly complex with their database setups. They’re also less readable than integers are, which can make reasoning with them harder. If storage space is a concern, UUIDs may be a bad choice. UUIDs are 128 bits long, which are twice the size of using BigInt and four times the size of using a normal Int. ![]() UUIDs do have a major downside though: their size. They’re also not sequential, meaning that you can’t guess other IDs based on a single value you have. Because of how they’re generated, it’s very easy to merge and move data between databases without the risk of conflicts. UUID stands for universally unique identifier and solves the mains issues with integers. This gives a strong argument for using UUIDs. Changing that ID in a request to your API could fetch data that you’re not supposed to have access to. Another issue is a security concern where if you have, say, an ID of 69, you can reason that there is a record with an ID of 68 and potentially one with an ID of 70. You could regenerate the data, but you could end up with key-issues on your client. One major one is that if you’re trying to merge data from two databases, you may end up with primary key conflicts. That being said, they do present some issues. ![]() For most projects, they work perfectly fine. They’re simple to work with and don’t take up a lot of space. Integers one of the most used types for primary keys. ![]() In this article, we’ll talk about PlanetScale’s approach to unique identifiers, why I went with it, and how I implement it in Prisma for my NextJS projects. And if anybody knows what they’re doing with database keys, it’s the team over at PlanetScale. I stumbled across an article from the PlanetScale team on why they use NanoIDs for their unique identifier in their APIs. With all these options to choose from, picking a PK can be overwhelming. Should you pick the tried-and-true int or go with the scalable UUID? Or maybe something like a CUID or NanoId would be a better fit for you. Using UUIDs is a good idea in brand new projects, but it might be wise to avoid transferring to UUIDs in a running production system unless you have a good reason to do so.If you’re like me, you have a feeling of existential dread whenever you’re deciding what to choose as a primary key for your database tables. You can no longer assume the ‘highest’ id is the most recent, which could be confusing for new developers to your codebase. MySQL is a more complicated proposition and I wouldn’t bother.ĪctiveRecord’s first and last scopes work in an unexpected way with UUID ids. If you’re using PostgreSQL this is a straightforward change and has little performance cost. This is a case where you are making a choice toward a little more complexity, but for good reasons. You can get round this by generating ‘public ids’ or ‘slugs’ for exposed URLs… but then, why not use a built-in tool?įrom a security perspective, using UUIDs prevents the situation where a malicious attacker could attempt to gain access to data by guessing a model id in your URLs. With UUIDs no-one can guess the size of your database tables, which might be information you are keen to keep secret. With an incrementing integer id the size of your data can be inferred from the outside i.e. The UUIDs are globally unique meaning you can know that different models cannot possibly have the same id and you can even assign them client-side or in other systems. Using UUIDs as the id in your Rails models instead of incrementing integers helps you avoid collisions. references :other, type: :uuid, index: true end end end But why? Class AddNewTable < ActiveRecord :: Migration def change create_table :related_model do | t | t.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |