Yeah, I think it's fairly normal to have an officer outside of or at the entrance to a polling location. They're not actually in the room with poll watchers, etc., and certainly nowhere near the private voting booths.
It has never felt inappropriate to me – maybe because I typically vote at a public school, where it's normal to see a crossing guard or public safety officer outside.
I buy a lot of fresh produce, which is way faster with a good cashier who knows all of the codes. I also tend to buy multiples of an item, which is also way faster when the cashier can swipe one and then hit 6x or whatevs.
And that's assuming the self-checkout system is working perfectly, which is rare. They often have some janky anti-theft sensors that freak out if you remove a bag or item from the bagging area. Self-checkout is fine or maybe even better if you have a few items, but for a cart full of groceries, it is inarguably way slower than a decent human cashier.
Very easy to switch, in my experience. It is like muscle memory. It might take a few weeks to get comfortable with manual, but once you do, it doesn't require much thought to switch gears.
It's a sequence that just happens, similar to typing. You still need to think about what you're saying, etc., but you don't have to consciously think, "now I'm typing an S."
I drive automatic now, but I miss stick sometimes. One of our family cars was a manual when I was a teen, 20 years ago.
I feel driving manual encourages a deeper focus on the road ahead and deeper connection with how your vehicle operates. You tend to plan ahead a bit more, be more aware of hills and curves, cars slowing down ahead, etc. – anything that'll make you need to switch gears. You could still have distracted driving, especially on highways, but driving stick lessens it, I think, though I have zero evidence to support that feeling.
If a combination of data should always be unique in a table, you should put a unique constraint/index on those columns to ensure that data integrity. I think that's mostly unrelated to the surrogate key vs natural key debate.
Your point about immutable keys is important, I think. A "natural key" can mean different things, as I understand the term. You could call a person's social security number a natural key, which for the record is a bad idea as they can change . But you could also call the combination of user_id and reservation_id a composite natural key, which is immutable and not so bad in my book. I'd still use a surrogate key though.
It might seem like I care about this more than I actually do. I've just found over the years of writing systems that I fairly often regretted not having a surrogate key on a table, but I've never once regretted adding a surrogate key that ended up not being essential.
What I've seen happen is that the data model expands/changes and I need to reference a join table. I might just start out referencing it by the composite natural key. Then the model changes again, and now I need to add another piece of data that changes the natural key. For example, maybe the natural key was (user_id, reservation_id), but now it's (user_id, reservation_id, membership_type_id). Now I need to think about anywhere I referenced that join table by the natural key.
I didn't know about it, but I don't find those slides compelling, not at all. For example, their response to the "keys shouldn't change" is "what is CASCADE for then?". That seems like a naive view of data.
It ignores things like integrating with other systems. If I export my data to an OLAP database, I can't just cascade that key change through it without manual effort.
It also ignores managing historical data. Maybe I don't want that natural key update cascaded everywhere. In their example of hotel room number, if that public-facing number changed (which does happen), I wouldn't necessarily want that cascaded everywhere. For example, I might need past reservations/invoices from before the change to keep the old room number, to match all correspondence with the guest, etc. Okay, so maybe you don't automatically cascade everywhere, but then you need some way to link that old room number and the new room number in all of your reporting.
Bleh. That's a lot of headache that can be greatly minimized with a surrogate key, for very little drawback in my experience. Sure, I can imagine scenarios where the performance impact or additional storage could actually be a real negative, but for your average CRUD app, I think surrogate keys add way, way more value than cost.
I actually prefer just using id as the primary key, and I like the explicitness of seeing the table/alias before the column in complex queries. I don't care too much about typing it out; reservation.id isn't longer than reservation_id, and the savings of USING vs ON seem minimal. I also don't care about deduplicating that one field, as I'll likely need to consider other duplicate fields in the results, like created_at or description.
But I can see arguments in both directions. I think the big thing is consistency. If you consistently use <table name>_id as the PK and your tooling doesn't fight it, then cool.
I do feel like this benefit breaks down rather quickly though. For example, if you wanted to track who created a guest record, you probably wouldn't name the column user_id as it's ambiguous. So you might use creator_id to signify it points to the user who created the guest, not to the user invited to the reservation – thus negating your ability to join to a user table via USING.
That's not to say it's a bad tip, just because there are cases where it doesn't fit. Definitely worth knowing. Thanks for sharing.