- 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
TRWTF is that my home address is 68 characters long.
Admin
TRWTF is that you can now create an entry without ANY Zip code. But really who would ever do this ;) .
Admin
A variable varchar, perfectly cromulent!
Admin
Admin
Even better: now you can have multiple ZIP codes! Because of the anti-pattern reuse, this will cause havoc somewhere due to the inevitable typo and/or forgotten "else"...
Admin
I've worked with a system that had similar problems but solved it rather elegantly. Every customer had a "comment" field for internal use and if the address didn't fit in its designated field it simply continued over into the comment field, giving another 255 characters to work with.
Admin
I don't know what it is about the relational database and SQL that see to inspire the most bizarre, creative, and WRONG solutions to problems.
Oh sure people come up with all kinds of WTFy way to abuse and misapply other software tooling and data structures; but relational data and SQL seem to draw the crazy out of people. Which I find odd because when you think about other languages and other persistent data storage methods most of them off more choices in terms of control structures and storage classes/objects/formats and yet rarely do the the creatively stupid come up with WTFs that are really on the level of their counter parts working with SQL on top of relational data.
Admin
TRWTF is "zip code". It's ZIP (Zone Improvement Plan) code, or postal code.
Admin
Though there are languages which actually come with persistent storage of one kind or another; "database" is the persistent storage every n00b knows and understands ("understands" as in "knows how to spell", but still, he is able to find the "this i show you do $X in $yoursqldb" "tutorials"). Putting together a few of these can generate abominations quite easily.
Admin
The real WTF is of course that US postal codes in the 5+4 versions are usually displayed (or entered) including the separator, i.e. 18010-0000 (see http://pa.postcodebase.com/category/city_name/ACKERMANVILLE)
So unless there is some client side logic fixing this (i.e. removing the minus), the bad job was not even done correctly, since a column like Zip10 is missing in the database.
Definitely a great WTF on a monday!
Admin
TRWTF is that they're missing out on all that lucrative business in Canada. Eh?
Admin
Admin
It is not (hopefully) an antipatter. No everything stupid is a commonly repeated scheme of things.
Bappo
Admin
Admin
Mmmmmmmmm Antipasti! Which reminds me, lunch time!!!
Admin
Admin
Admin
Putting other things in the middle, like a dash, confused earlier versions of the text reading software, so it would get kicked off to a human to read and figure out what is going on with it. Bad Code:
Admin
Admin
Don't be silly, Antipasti is just a pasta dish which has includes thiotimoline in its recipe, whose taste arrives on the tastebuds before you actually start to eat it. Brave practicitioners of experimental physics who want to see what happens if, on tasting it, then decide not to actually eat it, tend to find they wake up in the morning with a rather worse hangover than usual.
Admin
So it won't take zip + 4 because that requires ten characters. And what does the insert statement look like? Does it check input lengths? I can't see this passing a minimal QA test.
Are any of these stories true anymore? Were any of them ever?
Admin
Some great validation there...
Admin
While I can't say this universally (I've worked with some very good DBAs), it often seems as if they've never developed software before.
For example, our genius DBA and his buddy on a contract (who was the expert in the field put together a system about a year ago to do a lot of processing of data to allow reports to run against the processed data.
Setting aside the parts about the reports being wrong (in the rare case they actually ran to completion) when doing a demo, they built this grandiose system to connect which stored procedures to run to another piece of data, table X.
So, for row 1 in table X, they could map it to collect stored procedures sp1, sp2, sp3... for row 2, it might run sp2, sp5, and sp6. Fine, maybe a nice abstraction...
Except in this mapping, they used the 'name' field from table X. When we discussed this, I pointed out the name field has an online admin function, and could change at any time, unlike the UniqueId field, which is an identity.
I was told that use of either field was simply a preference and equally valid, as either one could change.
I suppose that's theoretically true; someone could go into the database, set identity insert off, update the unique id to something else, then turn it back on, and the machine wouldn't run for row 2 in table X.
Or, they could unse the online function to administer the name column. Which, of course, was practically the first thing out of the box the users did.
Nothing like knowing your environment and building around the things which are likely to cause problems.
Chimpanzee-like attention to detail.
Admin
Admin
anyone else thought from the title this was going to be about a zip code field being confused with a phone number?
Admin
Admin
The INSERT statement is prepared client-side so the server doesn't ever need to worry about it. See how simple that is?
Admin
What about mine? It's only 42. There's a lot of missing address fields.
Admin
Admin
While I can't say this universally (I've worked with some very good DBAs), it often seems as if they've never developed software before.
For example, our genius DBA and his buddy on a contract (who was the expert in the field put together a system about a year ago to do a lot of processing of data to allow reports to run against the processed data.
Setting aside the parts about the reports being wrong (in the rare case they actually ran to completion) when doing a demo, they built this grandiose system to connect which stored procedures to run to another piece of data, table X.
So, for row 1 in table X, they could map it to collect stored procedures sp1, sp2, sp3... for row 2, it might run sp2, sp5, and sp6. Fine, maybe a nice abstraction...
Except in this mapping, they used the 'name' field from table X. When we discussed this, I pointed out the name field has an online admin function, and could change at any time, unlike the UniqueId field, which is an identity.
I was told that use of either field was simply a preference and equally valid, as either one could change.
I suppose that's theoretically true; someone could go into the database, set identity insert off, update the unique id to something else, then turn it back on, and the machine wouldn't run for row 2 in table X.
Or, they could unse the online function to administer the name column. Which, of course, was practically the first thing out of the box the users did.
Nothing like knowing your environment and building around the things which are likely to cause problems.
Chimpanzee-like attention to detail.[/quote]
Parse error: Mismatched parentheses line 2 char 56 Segmentation fault [core dumped]
Admin
Parse error: Mismatched parentheses line 2 char 56 Segmentation fault [core dumped]
Admin
If you Americans for once take a look at the rest of the world, you'll notice that there is more variety to postal codes under the Sun than a mere mortal can fathom. See http://en.wikipedia.org/wiki/File:Postal_codes_by_country.svg. And that is with stripping non-significant dashes or spaces.
For such variety it is but appropriate that a varied variety of varchar fields be variably prepared. What is lacking in this is fields for 3 or 10 digits. And for true validation there should be separate fields for the alphanumeric varieties. Admitting codes of 6 digits and the canadian alternating abomination into the same field will surely thwart reasonable validation.
Admin
Still fails. The 9-digit zip code is usually 10 characters. There's a dash after the first 5.
Admin
Admin
This seems to be a new thing: Flood of design suggestions and no firm recommendations. Now that we've reached the age of patterns versus anti-patterns, it seems like there's a subversive movement to avoid use of either.
The best of all is these "experts" who say, "Well, there's lots of ways you can do it," and (carefully avoiding any indication of favor), "Which way you choose is up to you." Then, later, they tell you (gleefully), "You made the wrong choice."
I feel like I'm playing shell games.
Admin
Why is the dash even important for storing the number? The assumption can be made that if the zp code is more than 5 numbers, take the first 5, add a '-', pad the remaining digits to length 4, (the system may remove all zeros before a number 0004 becomes 4, so the 6 digit zip 123454 would be transformed into 12345-0004 appropriately) but that depends on the exact implementation of how the numbers are stored.
Admin
That person must have gotten the job of building web page input handling for credit card numbers that is not smart enough to remove spaces from the user input before validating.
Admin
Admin
I don't even understand that. I'm not a DBA, but I could have seen how bad this was before I even ever touched a computer. It's just mind-blowing how bad some pieces of code are.
That being said, this is one of those rare circumstances where the database software isn't great for validation, so it should loosely hold the data, and leave the country-specific validation up to the app. Similar to phone numbers.
Admin
Admin
But Canada has the postal code "H0H 0H0", so they're the most important country, when it comes to mail.
Admin
How come they are missing latitude longitude for U.S address? Our client want every address to be valid against google rooftop search.
Admin
Admin
Type in your address exactly as your country requires to receive something shipped from USA*:
(insert text area to collect address)
*Disclaimer: We are not responsible for errors in your address. The address used will be the one YOU provide. If you provide an incorrect, wrong, old, or otherwise undeliverable address and your package is returned to us. We will refund the cost of the item to you, less any shipping charges. If you have any questions about how to properly format your address; Please See usps.com and google.com for helpful shipping tips.
There problem solved forever. Give responsibility for the correct address to the consumer.
Admin
When addressing mail I usually just write all six characters with a space in the middle, but I tend to put a dash in between if I enter my address in a form.
When I started my most recent job I spent three days (yes, days) trying to get an offer letter sent to me by email. Every time I called to ask where it was I was told that it had been sent, but it still refused to arrive. Eventually someone got around to looking at their error logs and discovered that the custom built Recruit-O-Tron, Multinational Corporate Edition software they were using crashed completely whenever it so much as looked at a record with a seven character long postal code.
The funny things about this are that:
a) My email wasn't being delivered because of a problem with the postal code. I still have trouble accepting that that kind of problem can happen. b) I had already accepted the job offer a week earlier, c) I had also started working there two years before as a contractor, and d) The company happens to be one of the biggest banks in the country. I'm just going to keep telling myself that the systems used by HR have absolutely no connection to the ones that handle everybody's money but it never quite reassures me.
Admin
Back when ZIP+4 was introduced, a common technique on mainframe systems was to replace the existing "PIC 9(5)" (five digit, five byte, numeric, display character) field with "PIC 9(9) COMP-3" (nine digit, five byte, numeric packed decimal [BCD+sign]) to hold the longer format ZIP code. In the first case a ZIP like 60601 (downtown Chicago) would be stored as X'F6F0F6F0F1' (remember EBCDIC), and in the latter, 60601-1234 would be stored as X'606011234F'. This had the advantage of not requiring the layout of the records to be changed. Now most people at least converted the entire file at once. Some folks, in an effort to avoid the conversion, did a union (Cobol "REDEFINES") of both formats, and then did an "IS NUMERIC" test in each program reading that field to check which format was stored (the display and packed formats would never both pass the numeric test).
Admin
Admin
Admin
That said, I also have encountered cases where it's handy the referential integrity is maintained... As with most things, perhpas there is no silver bullet....
Admin
Basically we were having issues where poor data was being entered and the problem was perceived to be us not handling the data rather than poor data entry. I suggested that perhaps it should be made clear that errors in data might see your details processed incorrectly and cause somewhat of a headache for you in the long run....
There's only so much data validation that can/should/is safe to do before you need to stop the rubbish in. Bottom line (with anything computer) is that Rubbish can often result in rubbish out....
One of the fundamentals of data search and matching is to keep the data in the rawest format you received it - by all means manipulate copies of it in an attempt to match it to things, but always keep as basic a copy as you can. Enforcing too much formatting on data only means that when it doesn't work for someone, they'll squeeze it in some way - and then data changes its shape and potentially starts to look like something it's not.
Having people enter their address as they would expect it to appear on their mail is a great way of ensuring it's reasonably correct (and you can always do some checks and hints "did you mean to omit the country, and do you know it makes it hard to know who we should allow to mess up this delivery" just in case someone thinks a purchase from Sweden will know which Springfield their sending to....