5 ms·
Hello, creator here. This is (I hope obviously) just a short snippet you can and should use as a starting point to hack on. For smaller data sets, this is perfe
by minxomat 6y ago
Hello, creator here. This is (I hope obviously) just a short snippet you can and should use as a starting point to hack on. For smaller data sets, this is perfectly fine, but if you're at the point where you need this, you will certainly have business-specific requirements that I don't really want to bake into this from the beginning.
Here's my use case: I wrote this because I was (and am) working on a music streaming service, and I needed a youtube-like shortkey for public links to artists, albums etc. For my scale (~10,000 artists, ~120,000 tracks), I haven't run into any problems.
- sundbry 6y agoIf you do this in your application code, you can just store it as a 64 bit integer in postgres and optimize your index significantly, instead of using a varchar as the backing data type. These ids pack just right into 64 bits.
- hultner 6y agoCould it be backed by a 64bit integer while still exposing it as a well formatted code without relying on application layer intervention.
- aartav 6y agoCurious as to why not simply use UUIDs instead? Its extremely easy to use uuids as the primary key; make the column a `uuid` type and the `uuid-ossp` extension will generate them. Your sql would look like: CREATE TABLE posts ( post_id uuid DEFAULT uuid_generate_v4(), PRIMARY_KEY(post_id) );
- muminoff 6y agoIf you use Postgresql 13 version you don't need to install `uuid-ossp` extension. There's already built-in function to generate UUID which is `gen_random_uuid ()`.
- maxcan 6y agoI'd guess the idea would be to have more succinct URLs. As to whether or not primary keys should even ever be exposed in URLs, different story.