- Feature Articles
- CodeSOD
- Error'd
-
Forums
-
Other Articles
- Random Article
- Alex's Soapbox
- Announcements
- Best of…
- Best of Email
- Best of the Sidebar
- Bring Your Own Code
- Coded Smorgasbord
- Mandatory Fun Day
- Off Topic
- Representative Line
- News Roundup
- Editor's Soapbox
- Software on the Rocks
- Souvenir Potpourri
- Sponsor Post
- Tales from the Interview
- The Daily WTF: Live
- Virtudyne
Admin
Yuriy is dead wrong...how are you supposed to store NaN in a char(2)?
Admin
That reminds me of a system on which I worked that had a field full of four-digit numbers. All values (0-9999) had been used, and there was so much brittle code build around the exact schema that there was supposedly no easy way to expand the field. However, the field just happened to be of type VARCHAR2(4). So, one of my colleagues implemented a behind-the-scenes Base 36 storage scheme using characters 0-9 and A-Z in the field.
I guess it wasn't a complete WTF, except that I always thought the complexity of the "solution" was out-of-proportion with the need. I mean, I can see how such an approach might be a clever way to escape some really bad situation involving a mission-critical system. But I was skeptical of its applicability to this particular "accounting emergency."
Of course, I could have (and did) said the same thing about a great many things we did for those folks.
Admin
NSW and QLD are Australian states, which DO have three-letter acronyms. Therefore, a state field of length 2 for software which might be used outside the United States, or -- more likely -- will be used to store addresses of customers/users/etc. who live outside the United States is just plain wrong! Perhaps the state field should be named StateOrProvince, and in any case, the manager in this case should get a clue that there's more to the world than the U.S. That same manager should become familiar with http://www.columbia.edu/kermit/postal.html. The takeaway from that web page is not to memorize the address formats for 178 different countries, it's simply to realize that designing data entry and data structures for addresses is not as simple as you'd think.
By the way, I was born and bred in the U.S. and have always lived here, so this isn't the rant of a "foreigner."
Admin
What about ADO?
Admin
Spot on! As soon as Yuriy is done getting reamed by his boss, he's going to go after Chareth like a heat-seeking missle. Calling out your superiors over nonsense like this isn't going to make you any friends.
Admin
TRWTF is they let you debug apps with regexes, when you obvy don't know nothing about it.
Admin
Then Chareth should find another job. He was correctly pointing out inconsistencies, he had examples to back himself up, and he did it politely. If Yuriy really is a good developer, he would not seek revenge, he would simply state why the decisions were made. Period.
You know that if Yuriy's original schema was implemented as-is, it probably would have resulted in production problems, which would have promptly been dumped onto Chareth.
Copying the boss? Well, it depends. Sometimes you have a boss who has technical knowledge, and might offer helpful insight (obviously not the case here).
Admin
Bitching about the data types isn't supposed to be TRWTF.
It sounds like Chareth wrote the stored procedure and it was bad code. But it was NOT bad code due to the data types. He just wrote a bad SP with extraneous, unoptimized code.
Then Yuriy re-wrote the stored procedure with good code (maybe not paying the most attention to proper data-types, but using valid data types that have been proven to work for his scenario).
So Chareth's ego is beaten up and his panties are clearly in a bunch so deep it's triggering his gag reflex. He tries to find something wrong with Yuriy's code so he can point it out to the boss. The boss either sees it for a pointless narc attempt or being pointlessly nitpicky and shoots him down again.
Admin
The boss is wrong on point 1. For one thing, the US does have three letter place codes. APO/FPO, for example, to send to the armed forces. Although the post office will accept AE/AP as the place codes in those cases as well.
But if you ever decide to sell products to, say, Mexico, then you'd be well advised to have 4 letter place codes, since they do.
The standard for state codes is 4 letters, since there's no place that exceeds that as far as I know. However, a smart programmer makes it 6. Just in case. What's 2 more chars?
Admin
Chareth: "This code sucks Yuriy, I don't know how you can program." Yuriy: "I don't know how you can walk." Chareth: "Wha?" crack crack
Admin
If the boss responded so fast, my guess is that Chareth (probably Sharath, but I'm only guessing) is a pain in the ass with a reputation.
The real WTF is that this doesn't actually tell you the code differences that spawned the brew-ha-ha.
Admin
Cardinal Rule III: Bosses-bosses have been ratted on to their bosses before, so if you rate to your bosses-boss, chances are you're only going to get back a response that shows you how little you know, along with the pent up anger from someone who it's already happened to a million times!
Admin
Sorry, you're wrong. FPO, APO, etc. are part of the city field.
Military "state" codes are AA (Armed Forces America), AE (Armed Forces Europe), AP (Armed Forces Pacific).
Admin
<ob.CanadianPatriotism> Look up - we're larger than you, and on top. </ob>
Admin
[quote user="JamesQMurphy"][quote user="Capt Obvious] Spot on! As soon as Yuriy is done getting reamed by his boss, he's going to go after Chareth like a heat-seeking missle. Calling out your superiors over nonsense like this isn't going to make you any friends. [/quote]
Then Chareth should find another job. He was correctly pointing out inconsistencies, he had examples to back himself up, and he did it politely. If Yuriy really is a good developer, he would not seek revenge, he would simply state why the decisions were made. Period.
You know that if Yuriy's original schema was implemented as-is, it probably would have resulted in production problems, which would have promptly been dumped onto Chareth.
Copying the boss? Well, it depends. Sometimes you have a boss who has technical knowledge, and might offer helpful insight (obviously not the case here). [/quote]
You're right about the inconsistencies being an issue. Datatype consistency is important. But so is knowing how (and more importantly, when) to move an issue up the chain of command. Copying your boss' boss on something minor like this is like pointing your finger and yelling "See, see? I told you he's an idiot!"
All it really tells Yuriy's boss is that Yuriy can't manage his team. Maybe that's true...but pointing it out in this fashion isn't going to help Chareth's cause any. My read on the situation is that Chareth is being juvenile and immature. This is the sort of thing that turns managers into overbearing, micro-managing asshats.
Admin
HONK Wrong.
FPO is the "city" AP is the "state"
Admin
Beat me to it
http://www.usps.com/ncsc/lookups/abbreviations.html#states
Admin
Admin
Almost, Lower Canada, now Ontario, was asked to join the revolution. It would have been the 14th state, not the 51st.
Admin
I thought companies are only required to charge sales tax on states where they have a physical presence. This would easily explain why they would have a table with worldwide entities so they could ship to them, but a stored procedure to calculate tax would not need to calculate tax for QLD. And someone already point out that military addresses have a two letter abbreviation ("AP" for example).
Admin
The WTF is on Yuriry and his boss, not Chareth. I agree with what the other person typed about how he was "with Chareth". Also, someone else pointed out that there are ALREADY ZIPCODES with more than 2 characters in the database. The real WTF is the people who think Chareth is the WTF.
Admin
Everyone is missing the main SQL-design flaw here. The governments' state abbreviations should not be the primary keys.
The application should use INTEGER primary keys to the STATES table. The table stores the states' names and abbreviations for human readers only.
Then, only the STATES table has to change when new countries are added. The integer foreign keys referencing existing STATES will continue to be valid.
Admin
If they do, they'd probably assign a two letter abbreviation anyway, as in IQ for Iraq and CA for Canada (aka 'North Maine').
Admin
Which goes to the root of the matter- Chareth is trying to solve a business problem. He is confused by technical details which do not matter in the context of the problem. That is why he is a junior developer. (Of course, I believe the application has some data validation somewhere, which will, for example, prevent using the SP to calculate a US sales tax on something sold in Australia, or prevent an order for a grazillion dollars, or whatever. Because all applications do. OK, maybe not. But Chareth's piece should not make it possible to do such things without even blinking, which is what it seems he was going for.)
Admin
Yeah, I'm seeing it right now. Our company promoted one of our customer support managers to be a Dev manager. Until then the only code she'd ever seen was on a kid's placemat at Denny's.
Admin
Admin
I believe I said IQ not IA. So, we'll have IQ and IR for Iran. I'm the decider, hehehe!
Admin
Admin
Were I interviewing both of them, based on this WTF, I'd hire Chareth and pass on Yuri.
Admin
Admin
No, if Chareth wants to stop getting stabbed in the heart, he just needs to get a grip on reality (which sadly is often missing in recent college grads).
Admin
TRWTF here is an able manager.
Wait... there's something wrong with the universe IT'S THE HADRON COLLIDER! RUN!
An actual WTF on a capable manager? Scary.
Admin
Paul
I just want to add that even if the article talked about the data in the DB it would still be specious for two reasons. 1) I’m pretty confident that most DBMS don’t allocate the maximum size of a field when the value is smaller than the Maximum size. 2) Even if the did it’s a pretty small amount, 4 bytes per row in MS SQL and 6 bytes in Oracle. This translates into 4MB to 6MB per million rows. This amount of disk space shouldn’t be a consideration in most applications.
For thoes who care about how I came up with the numbers:
SQL PRINT datalength(9999999999999999.999999999999 ) - datalength(99999999999.9999)
Oracle SELECT VSIZE(9999999999999999.999999999999 ) - VSIZE(99999999999.9999) FROM dual
Admin
The application calculates US taxes, so why TF should it care if some other country somewhere uses a different set of abbreviations for States? This code will never get called for Queensland, or for some former Soviet republic that uses three umlauts and a picture of a tractor as a state abbreviation.
The idea of having an integer key for each state is just too much. The US Postal Office already gives us unique keys for each US state, so why complicate things?
Almost anybody in the US knows that VA is Virginia. How many know that you've picked the number 12 for Virginia instead? How many know this at 3:00 AM on a Sunday when they are trying to debug your overcomplicated application?
Admin
Were Rachael's asterisks insufficient? That data is in the database, and we have no reason other than the boss's snarky note to assume that this method will somehow magically never hit them.
Admin
I think everyone is missing TRWTF here. The width of the datatype thing is just a red herring; it doesn't really matter one way or the other. TRWTF is that Chareth's code is so bad that it failed a code review three times. When another developer tries to set him straight, he can only focus on these insignificant details in an attempt to justify that his version is better.
I'm sure if we had access to the stored procedures we'd see that Chareth's is a total mess and that this column width thing is a total non-issue.
Admin
If God had wanted us to think Canada was bigger, he wouldn't have given us the Mercator projection, eh?
Admin
Admin
FPO is analogous to a city, not a state. The state code is still the two-letter AP, as the previous poster indicated. There are actually three "state" codes for military addresses: AE (Europe/Canada/Mideast/Africa), AP (Pacific), and AA (Atlantic).
There are two "city" codes: APO and FPO. APO is Army and Air Force, while FPO is Navy, Marines, and Coast Guard.
Admin
There are obviously some people reading this that have never had to maintain code that was written for "U.S. only" software that eventually expanded into international markets. It's people like Yuriy and the boss that don't have the foresight to look at the 2 character state abbreviation and say "I know we are U.S. only right now, but what if we expand into international markets in the future?" Just do it right the first time. I would much rather be maintaining Chareth's code in the future.
Admin
Additionally, the USPS has a complete list of US address abbreviations. It does not include Canadian or Mexican state codes, but it does include other non-state codes, such as DC (District of Columbia), American Samoa (AS), and so on. All are two-character.
Admin
From USPS ("Military" States): Armed Forces Africa AE
Armed Forces Americas AA (except Canada)
Armed Forces Canada AE
Armed Forces Europe AE
Armed Forces Middle East AE
Armed Forces Pacific AP
With the way things are going, maybe the Middle East needs it's own code... How about SH(it)
Admin
Can someone point me to an international schema for storing addresses? Most of the systems I've worked on were designed with the US in mind. Canadian address sort of work (not really). Mexico and the rest of the world, not supported at all. Is there an ISO or other standards committee address format that is international?
Admin
Intersting that at no point does it mention whether or not the money type is lossy or not. I'd think that would be more important than just its range.
Admin
The USPS state code is in the STATES table. A database sequence generated the number 12 for the row ('VA', 'Virginia'). The relation between state codes and keys is documented in the DB, and is not arbitrary!
In fact, the STATES table, presented as a menu, prevents users from entering invalid state codes in the first place. The database FOREIGN KEY for ORDERS.STATE_ID validates the ORDERS record for you.
All you have to do is join STATES to the ORDERS table to see the state code in the address. If you can't write such JOIN clauses, then you are not qualified to use SQL at all.
Admin
Calculating a sales tax merely by the state and/or zip code is broken.
For example, in my zip code, there are two different sales tax rates depending on your location.
In addition, depending on what you are selling, there may be sales taxes in some states but not others. For example, in some states, no sales taxes are applied to food items while in other states they are.
Admin
Wait, I thought Rule One was to be very careful when speaking to a small bald wrinkly old man....
Admin
You couldn't be more wrong.
http://www.postgresql.org/docs/8.3/interactive/datatype-money.html
Admin
You couldn't be more wrong
http://www.postgresql.org/docs/8.3/interactive/datatype-money.html
(meant to quote the one I was referring to)
Admin
To avoid conflicting with existing states we need 3 alpha
IRAQ = IRQ IRAN = IRN