4 ms·
I once made that argument, we ended up with reservation_name, I regret I ever said anything about it. Apparently, it made joins more clear, I seriously wonder
by fleitz 11y ago
I once made that argument, we ended up with reservation_name, I regret I ever said anything about it.
Apparently, it made joins more clear, I seriously wonder how often people fucked that up for them to think it was a good idea to prefix every fucking column with its table name.
It's like when I see unit tests for setters and think, gee, setters seem pretty straightforward to me, how often to people fuck them up?
- developer2 11y ago>> we ended up with reservation_name That's absolutely terrifying. You've just provided my subconscious with new material with which to populate my nightmares. How did the code using that database operate? Were you using "reservation_name", or did the application revert the naming scheme by mapping the column to "name"? Either way, FML.
- vmasto 11y agoCould you elaborate on why this is so awful? (genuine question)
- bottled_poe 11y agoI can think of a few reasons: - The field name implies that the primary key field is a string. This entails numerous issues (eg. How do you generate a new unique ID?) - It is not obvious that the field is the primary key. - A 'name' property on a reservation doesn't make sense. Is it the name of the person making the reservation? How can this be unique? etc.
- developer2 11y agoMy use of "name" was a poorly chosen example to tie to the concept of a reservation. I just chose it because "name" is an extremely common and unambiguous column in many tables.
- fleitz 11y agoToo much typing / line noise.
- PeCaN 11y agoFFS, it's just reservation.reservation_name, it's not like he's parsing HTML with regular expressions or something. Like... big deal.
- deleted 11y ago[deleted]
- kbenson 11y agoYes, you always have to be really careful when positing an absurd solution to make a point; there's always the risk you'll be taken seriously. :)