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

551–560 of 568 posts

Re: You'll regret using natural keys

#551

Post by shkkmo »

randomdata wrote: post #483
shkkmo wrote: post #482

Earlier quoted context omitted.

Possibly, you don't actually know since it is external data.

We do know because the database owner has openly talked about how the keys are derived. That still doesn't make it a good key for your database, but I can assure you that the world doesn't revolve around you. It is someone's surrogate key – therefore it is a surrogate key.

You seem to be insisting on a semantic interpretation that makes the term less useful. A third party's surrogate key should not be considered a surrogate key when in your system. It doesn't matter how that key was generated, only that the semantic meaning of the key is outside of your control.

Re: You'll regret using natural keys

#552

Post by ltbarcly3 »

yellowapple wrote: post #201
aaronbrethorst wrote: post #69

Earlier quoted context omitted.

Fast-forward a couple years: now I have scripts that launch sub-tasks more than once a second.

So use timestamps with sub-second precision, which virtually every SQL database supports (even ones like SQLite that don't have built-in date/time types).

I don't think you know enough about how databases work to even try to be giving advice.

The timestamp generated in a transaction is generally the time the transaction started, which means it is always the same within the same transaction.

Re: You'll regret using natural keys

#553

Post by JackSlateur »

duped wrote: post #545
JackSlateur wrote: post #541

Earlier quoted context omitted.

Bah ? Got a new car, used it for 150k km Tweak the odometer and set it to 50k, sell the car How could the government know I cheated ? Especially for an old car which are not connected (so even the manufacturer cannot tell) (btw, this is used in thief networks to refurg stolen cars)

> How could the government know I cheated You would have to perjure yourself on your yearly registration, when you get emissions testing you would need the tech to perjure themselves, and if you go to any mechanic that reports the mileage to the state (which some do, depending on the state) you would need them to perjure themselves too. > Tweak the odometer and set it to 50k, sell the car If the most recent registrat…

It may be important to note that here in France, there is no yearly registration nor emissions testing

We only declare odometer's when we sell the car. There is a technical checkup every two years which may be send that intel to the gov. Does not matter anyway : what matters is that a counter that should only be increased can be decreased, because car manufacturer do not care about any kind of IT security

Re: You'll regret using natural keys

#554

Post by hot_gril »

hot_gril wrote: post #513
cogman10 wrote: post #512

Earlier quoted context omitted.

As always, depends on the implementation. Hash maps should generally always have faster lookups than Btree based structures. However, they'll have slower writes especially when contested. A key issue hash tables have to deal with is what happens when a remapping needs to happen. For example, when 2 keys have the same hash. In that case, locking becomes a lot more messy. For a btree this is simpler. It's built to be a…

Hm yeah, now I'm wondering how MySQL implements it. Consistent hashing is one way to limit the scope of a remap.

(But it seems like an ordered index is fundamentally easier for write performance)

Re: You'll regret using natural keys

#555

Post by selcuka »

ltbarcly3 wrote: post #552
yellowapple wrote: post #201

Earlier quoted context omitted.

So use timestamps with sub-second precision, which virtually every SQL database supports (even ones like SQLite that don't have built-in date/time types).

I don't think you know enough about how databases work to even try to be giving advice. The timestamp generated in a transaction is generally the time the transaction started, which means it is always the same within the same transaction.

Obviously sub-tasks will not typically be in the same transaction.

Re: You'll regret using natural keys

#556

Post by poops »

naasking wrote: post #544
praestigiare wrote: post #540

Earlier quoted context omitted.

Because - and _ break text selection in existing systems you do not have control over, if you use those characters your ids will become harder to select.

Someone already made this point, and once again, "break" is completely undefined. It is not at all impossible or even difficult to select text with - or _, so what's "broken" exactly? At worst it takes one extra step to extend the default selection. These are such weird objections.

I work across multiple machines with different pointing devices (regular mouse, vertical mouse, touchpad), and have no issues double clicking to select a word. Dragging from the start of a word to the end can sometimes take multiple tries. I may miss the first letter. I may drag too far. The vertical mouse isn't great at holding a selection. It's not a huge deal, but it's an annoyance that I don't run into working with Stripe IDs.

Re: You'll regret using natural keys

#557

Post by M95D »

hehdhdjehehegwv wrote: post #445
M95D wrote: post #130

Earlier quoted context omitted.

Yeah, fsck your co-workers and your replacement when you quit.

If you’re good to your future self you’re also good to them.

Invalid argument. Very rarely your future self will work in that company or on the same project. Even if someone plans to keep his job for a long time, writing for his's future self usually means making himself non-replaceable by writing unreadable code.

Re: You'll regret using natural keys

#559

Post by longerd2 »

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…

How is this readable?

Re: You'll regret using natural keys

#560

Post by helpfulContrib »

naasking wrote: post #539
Too wrote: post #527

Earlier quoted context omitted.

Usually one is not in control over every place where text can be selected. As a developer I will be exposed to ids being displayed in code, terminals, browsers of various sorts, database editors, json dumps, text editors, api responses, chat messages, you name it.

Sure, I agree. I'm not sure what point you're trying to make though.

The entire point of making this form of ID is to make it a friendly user experience, to create an ID that can easily be communicated by a person over the phone to another phone, to make an ID that is easy to click, double-click, tap (with fingers on a touch surface), double-tap, hold-and-select and tap to 'copy', and so on.

The _ and - symbols make this difficult in the edge cases of all of the above. Do you call it dash, or underscore? Line? Hyphen? Binder-strich?

&etc.

I would have gone with adding the @ and ~ symbols, those are at least parsable in human form as well .. ".. email symbol and squiggly thing .. "

Post reply on HN