[fleitz]

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]

>> 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.

[PeCaN]

FFS, it's just reservation.reservation_name, it's not like he's parsing HTML with regular expressions or something. Like... big deal.

[kbenson]

I'm not sure if this is humor going over my head, or seriousness smacking me in the face.

[davvolun]

http://stackoverflow.com/questions/1732348/regex-match-open-...

[vmasto]

Could you elaborate on why this is so awful? (genuine question)

[bottled_poe]

I 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]

My 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]

Too much typing / line noise.

[kbenson]

Yes, 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. :)