Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

You'll regret using natural keys

blog.ploeh.dk

Post reply on HN
Print view View original

281–290 of 568 posts

Re: You'll regret using natural keys

#281

Post by fnordsensei »

kodisha wrote: post #252
strnisa wrote: post #220

Earlier quoted context omitted.

Thanks for all the improvement suggestions! Taking them into account, the `makeSlug` function becomes: function makeSlug(length: number): string { const alphabet = "0123456789abcdefghjkmnpqrstvwxyz"; let result = ""; for (let i = 0; i

Or, just use cuid2 [1] + prefix. [1] https://github.com/paralleldrive/cuid2

One thing I’ve been looking for in an ID generator is a way to supply a blocklist. There are a number of character combinations I’d like to avoid in IDs, because they might be offensive or get stuck in filters when copy-pasted (e.g. in a URI).

This can be solved in user space by regenerating if the character sequences are detected, but this a) skews the distribution, and b) potentially takes time, especially when the ID generator is made to not be “too fast”. I want to generate a single ID that passes the blocklist in a timeframe that is not too fast, if that makes sense.

Is there an ID generator that takes this into consideration?

Re: You'll regret using natural keys

#282

Post by [deleted] »

brigandish wrote: post #134
yashap wrote: post #97

Earlier quoted context omitted.

This is bad advice. Say I have a user table, and the email is unique and required, and we don’t let users update their email, and we don’t have user deletion. If I’m going natural PK, I make email the primary key. But … then we add the ability for users to update their email. But it should still be the same user! This is trivial if we have a surrogate primary key, a nightmare if we made email the natural primary key.…

You require three fields (or four): email at registration, a date for that entry (together these create a natural key), and current email (this one not part of the key and editable). We're almost all the way to a Tag URI[0], so you could combine it with the user's name or username or any other identifier that fits the spec[1] (you could even use the website's own name) and you have a (definitely two thirds, probably…

[deleted]

Re: You'll regret using natural keys

#283

Post by rsynnott »

delusional wrote: post #122
Kon-Peki wrote: post #30

> how about a personal identification number? In Denmark we have the CPR number, and I understand that the US Social Security Number is vaguely analogous. The US SSN is not guaranteed to be unique, the SSN assigned to a person could change, there is no guarantee that a person with an SSN assigned to them is a US citizen, and there is no guarantee that a US citizen has an SSN - they must be requested, and you don’t ne…

We have the same problem in Denmark, most people just don't realize it. At my dayjob we get at least one person every year who changes gender and consequently gets a new SSN (the final digit is supposed to signify gender). Most people don't store SSNs so they never realize, but it does happen fairly frequently.

In Ireland, until the 90s, if a woman got married, she gave up her PPS number (essentially a social security number) and took her husband's, with a 'W' appended (this fact tells you a lot about pre-90s Ireland...) If she subsequently divorced or the husband died, she got a _new_ PPS number.

While this was abolished in the 90s, _some people still have these 'W' numbers_, ticking timebombs for anyone relying on them as a key.

Re: You'll regret using natural keys

#284

Post by hprotagonist »

8372049 wrote: post #265
corobo wrote: post #247

Earlier quoted context omitted.

Ooh interesting. It looks like I have either misinterpreted or found a source that misinterpreted (it was a few years back, unsure if I came to the conclusion or found it). I'll have to update my notes, cheers! Apologies for the wetbrain hallucination, HN!

I'm not sure you're hallucinating. The dictionary I checked lists the printing and journalism terms separately. It's quite possible they have diverging etymologies, meaning both can be correct: 5. Print. a. a thick strip of type metal less than type-high. b. such a strip containing a type-high number or other character for temporary use. c. a line of type in one piece, as produced by a Linotype. 8. Journalism. a. a s…

or the journalism term itself diverged from the typographic one.

Re: You'll regret using natural keys

#285

Post by naasking »

vanderZwan wrote: post #157
strnisa wrote: post #151

I've become a fan of unique, relatively short and "human-readable" IDs, such at the ones used by Stripe, e.g. `cus_MJA953cFzEuO1z` for an ID of a customer. Here's a Stripe dev article on the topic: https://dev.to/stripe/designing-apis-for-humans-object-ids-3... If you use JavaScript/TypeScript, you can make them like this: function makeSlug(length: number): string { const validChars = "ABCDEFGHIJKLMNOPQRSTUVWXYZabcde…

Nice! For the record: the valid chars string is 62 characters, so naively using a modulo on a random byte will technically introduce a bias (since dividing 256 values by 62 leaves a remainder). I don't expect it to really matter here, but since you're putting in the effort of using crypto.randomBytes I figured you might appreciate the nitpick ;). Melissa E. O'Neill has a nice article explaining what the problem is, a…

> For the record: the valid chars string is 62 characters, so naively using a modulo on a random byte will technically introduce a bias

Indeed, there's no reason you couldn't just add "_" and "-" or "." as well to complete the set. Your identifier will still be URL-safe. I've been using this type of encoding for years [1] for these kinds of ids to use in URLs, and encoding/decoding is super-fast with some bit shifts. And unlike Base64, you don't need padding characters.

[1] https://sourceforge.net/p/sasa/code/ci/default/tree/Sasa.Web...

Re: You'll regret using natural keys

#286

Post by rsynnott »

cheema33 wrote: post #227
ThePowerOfFuet wrote: post #214

Earlier quoted context omitted.

Many, many countries do not.

Vanity plates are essentially free money for the govt. I am surprised every govt. body doesn't go for it. If you really don't like them, make them super expensive.

Tbh when you factor in the administration, I'd question whether they actually make any money on these.

Re: You'll regret using natural keys

#287

Post by TeMPOraL »

crabmusket wrote: post #111
huygens6363 wrote: post #73

Earlier quoted context omitted.

There is a model of a thing and there is a row that stores a representation of that model of a thing. They both are things. Ignoring the last one might be tempting, but it’s not practical. Interestingly your own way of thought is applied, but now a level deeper again. How do you model a row? What makes it unique? A surrogate ID is the only sensible unique identifier for such a thing as there is no “natural key” that…

> They both are things. Corollary: your app is part of the real world.

Furthermore: bugs in your app are part of the real world, so woe to those who used keys from your app as natural/external keys in their app.

Re: You'll regret using natural keys

#288

Post by hprotagonist »

mikedelfino wrote: post #268
Kon-Peki wrote: post #30

> how about a personal identification number? In Denmark we have the CPR number, and I understand that the US Social Security Number is vaguely analogous. The US SSN is not guaranteed to be unique, the SSN assigned to a person could change, there is no guarantee that a person with an SSN assigned to them is a US citizen, and there is no guarantee that a US citizen has an SSN - they must be requested, and you don’t ne…

How to uniquely identify an American citizen?

ha ha only serious; ask them for their papers and if they say “who the fuck are you?”, they’re americans!

a slightly more serious answer: you largely don’t. The US doesn’t have a national ID, proof of birth is not even close to standardized, etc.

Re: You'll regret using natural keys

#289

Post by bjourne »

konschubert wrote: post #251
bjourne wrote: post #249

Hard disagree. You create tables for them to be queried by applications. For the Restaurants example the application clearly wasn't designed to handle Restaurant entries whose only field differs is rank. Consequently, you shouldn't allow data the application can't handle. Whenever the time comes and you think "ah, wouldn't it be great if multiple people could review the same restaurant in the same year?" you change t…

You can use a UUID as a primary key and still enforce uniqueness on a combined index of city and name.

But what's the point? You're complicating the data for no apparent gain. Only terrible RDBMSes which don't support multi-column keys require surrogate keys.

Re: You'll regret using natural keys

#290

Post by corobo »

hprotagonist wrote: post #284
8372049 wrote: post #265

Earlier quoted context omitted.

I'm not sure you're hallucinating. The dictionary I checked lists the printing and journalism terms separately. It's quite possible they have diverging etymologies, meaning both can be correct: 5. Print. a. a thick strip of type metal less than type-high. b. such a strip containing a type-high number or other character for temporary use. c. a line of type in one piece, as produced by a Linotype. 8. Journalism. a. a s…

or the journalism term itself diverged from the typographic one.

Aye this is what it seems to be having double checked the reply's claim

Got to the Wikipedia page https://en.wikipedia.org/wiki/Slug_(publishing) which could possibly support the slimy conclusion of "it's a trail through the process" but that article has an etymology section that refers to the metal slug

I guess it could mean both depending on whether you're looking for the meaning of the word or the meaning of the concept but I didn't find any other slimy grub references (via an admittedly limited double check)

Post reply on HN