• pangalactic (unregistered) in reply to Geoff
    Geoff:
    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.

    I wish I knew why.

    90 percent of databases is about storing information so that when you need to retrieve it later, you just have to provide a database name, table name and some key information, and it comes back. Oh and you can retrieve a bunch of related information at the same time, as long as you arrange your database properly.

    10 percent of databases is about other stuff. Mainly performance and other minor complications.

    But for some reason the way most people think about databases is 90 percent other stuff: performance, security, scalability, foreign keys, denormalization, nulls, stored procedures, GUIDs, compound vs composite keys, shards, grids, big data, materialized views, SQL injection attacks, NoSQL, and triggers.

    As Scotty once said on Star Trek: “The more they overthink the plumbing, the easier it is to stop up the drain.”

  • Muphry (unregistered) in reply to Compiler

    [quote user="Compiler"]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][/quote] ... with a mismatched [/quote] tag, classic!

  • foo AKA fooo (unregistered) in reply to rwessel
    rwessel:
    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).
    Now we've finally learned why EBCDIC is bettar than ASCII. X'3630363031' wouldn't work.
  • Swedish tard (unregistered) in reply to dignissim
    dignissim:
    postal coder:
    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.
    The lack of a "Country" column should be a hint that this particular table isn't intended to store international addresses.

    An annoying stance that has cost a few american buisnesses sales quite a lot of times when customers could not enter their address, despite the webpage claiming global shipping. It's utterly retarded. Names, adresses, phone numbers and a few other personal details should only ever be stored in a long, single string (or varchar) each. Getting it any more specific (such as first/last name) will invariably fuck you in the ass, hard, once the system outgrows it's initial spec. MAking shit MORE complex to fit a smaller requirement is just fucking daft in ways that I lack words to describe.

  • Bob (unregistered) in reply to 3GSr
    3GSr:
    Yes, I love when I have calculations and I need to insert one, and the references don't change (think of a bank statement where you have to insert a transaction between B and C....it helps if the stuff moving from C to D now points to the inserted C, instead of the original B)

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

    TRWTF is casually demolishing any distinction between data, rules, and presentation; yet still wondering if there's a "silver bullet" to save you from the swamp you wandered straight into.

  • anonymous (unregistered) in reply to Anomaly
    Anomaly:
    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.
    Ugh, no. That is even more WTF-y. ZIP codes are strings. US ZIP codes are 9-digit strings. No padding or unpadding should occur except for (possibly) the hyphen. In your example, how do you know that 123454 is supposed to be 12345-0004 and not, say, 01234-0054? The zeros are significant and should not be removed. The hyphen is not significant and it's up to you whether to remove it or not.
  • Neil (unregistered) in reply to Bob
    Bob:
    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 woke up in the morning with a rather worse hangover than usual.
    FTFY
  • Nick (unregistered) in reply to faoileag

    My Zip+4 goes to 11 !

  • Nick (unregistered) in reply to faoileag
    faoileag:

    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!

    My Zip+4 goes to 11 !

  • anon (unregistered) in reply to anon

    You have a different definition of "elegant" than the rest of the world.

  • anon (unregistered) in reply to anon
    anon:
    anonymous:
    TRWTF is that my home address is 68 characters long.

    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.

    You have a different definition of "elegant" than the rest of the world.

  • Jay (unregistered) in reply to 3GSr

    [quote user="3GSr"][quote user="anonymous"]Yes, I love when I have calculations and I need to insert one, and the references don't change (think of a bank statement where you have to insert a transaction between B and C....it helps if the stuff moving from C to D now points to the inserted C, instead of the original B)

    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....[/quote] In Excel you use the $ symbol to lock a reference. If you calculation points at cell D5, that will change if you insert/delete cells.

    If you use $D$5 instead, then not matter how much the sheet changes, the calculation will read from D5.

    $D$5 locks both row & column, you can use either or both. Handy for when you drag a formula down and want to reference the first column or something.

    And in many cases you should be useng names ranges anyway.

  • anonymous (unregistered) in reply to Jay
    Jay:
    In Excel you use the $ symbol to lock a reference. If you calculation points at cell D5, that will change if you insert/delete cells.

    If you use $D$5 instead, then not matter how much the sheet changes, the calculation will read from D5.

    $D$5 locks both row & column, you can use either or both. Handy for when you drag a formula down and want to reference the first column or something.

    And in many cases you should be useng names ranges anyway.

    Locking the reference with $ will lock the reference to that cell, not to its address. If the cell moves due to cells being inserted/deleted, or the cell being cut and pasted elsewhere, the reference will update to still point to that cell (no longer in D5).

    If you actually do need a formula that always references the cell at D5, regardless of cells being moved around, any of the following will work (assume this goes in cell A1 for the sake of the formula with A1 that needs to calculate the offset relative to itself):

    =INDIRECT(ADDRESS(5,4))
=INDIRECT("D5")
=INDIRECT("$D$5")
=OFFSET(A1,5-ROW(),4-COLUMN())
=OFFSET(INDIRECT(ADDRESS(ROW(),COLUMN())),5-ROW(),4-COLUMN())

  • Miguel Chavez (unregistered)

    Very informative but all i have been seeing is runaround no soundly put advise one long claim letter and too much misinforming data.. Trust starts with trust when there is none all is not well

  • anonymous (unregistered) in reply to Miguel Chavez
    Miguel Chavez :
    Very informative but all i have been seeing is runaround no soundly put advise one long claim letter and too much misinforming data.. Trust starts with trust when there is none all is not well
    Testing your new Markov chain generator, I see...
  • anonymous (unregistered) in reply to anonymous
    anonymous:
    Miguel Chavez :
    Very informative but all i have been seeing is runaround no soundly put advise one long claim letter and too much misinforming data.. Trust starts with trust when there is none all is not well
    Testing your new Markov chain generator, I see...
    Go is to the fountain. No Quack.

Leave a comment on “Calling All Zip Codes”

Log In or post as a guest

Replying to comment #:

Log Out

« Return to Article