• (cs)

    Just several problems?

    Don't you love these kinds of applications? Probably written by some idiot who picked up a TEACH YOURSELF ASP IN 24 HOURS book (and the same with SQL) and got right to work hacking away. Fucking Morts.

    Oh, and first!

  • (cs)

    "I'll leave those as an exercise for the reader to commit seppuku over."

  • (cs)

    Cool! A Stupid Database Table WTF! It's been a while since we've had one of those.

  • (cs)

    264 columns? is it just me, or shouldn't the developer around the 20, 50, 100, 150 etc marks be thinking "there has to be a better way"

    i'm flabbergasted

  • Brian B (unregistered) in reply to ObiWayneKenobi

    This just goes to show once again that if you're "programming" by copying, pasting, and change the number on the end, you're doing something very wrong.

  • An apprentice (unregistered)

    Aaargh. Why is it that always when a truly horrible atrocity shows up on this site, it involves SQL and relational design?

  • (cs) in reply to ObiWayneKenobi
    ObiWayneKenobi:
    TEACH YOURSELF ASP
    I don't think that this has anything to do with the choice of implementation language...
  • T (unregistered) in reply to A Nonny Mouse
    A Nonny Mouse:
    264 columns? is it just me, or shouldn't the developer around the 20, 50, 100, 150 etc marks be thinking "there has to be a better way"
    He or she may have used a loop to create the columns.
  • T (unregistered) in reply to snoofle
    snoofle:
    ObiWayneKenobi:
    TEACH YOURSELF ASP
    I don't think that this has anything to do with the choice of implementation language...
    No, but with TEACH YOURSELF ... IN 24 HOURS.
  • (cs) in reply to snoofle
    snoofle:
    ObiWayneKenobi:
    TEACH YOURSELF ASP
    I don't think that this has anything to do with the choice of implementation language...

    All due respect, I think you missed the point. The key point was the "IN 24 HOURS" part, basically insinuating the person who did this was a no-talent hack who had little to no idea about anything having to do with programming prior, hence why their SQL is so atrocious.

  • (cs) in reply to T
    T:
    A Nonny Mouse:
    264 columns? is it just me, or shouldn't the developer around the 20, 50, 100, 150 etc marks be thinking "there has to be a better way"
    He or she may have used a loop to create the columns.

    okaaayyy.. but if they had to resort to this "loop" trickery you speak of to generate their columns, shouldn't they have been thinking "there has to be a better way"

  • bd (unregistered)

    TRWTF is that databases don't support array fields. We all know from previous articles that every time you see bunch of variables with names containing numbers in a sequence, you can refactor all that into a single array.

    On the other hand I must commend on the very straightforward schema design which mirrors the user interface almost perfectly. That's something you could explain even to your pointy-haired boss without his eyes glazing over.

  • Tom (unregistered) in reply to An apprentice
    An apprentice:
    Aaargh. Why is it that always when a truly horrible atrocity shows up on this site, it involves SQL and relational design?

    Well, this one didn't involve "design" in the traditional sense.

  • (cs)

    Databases? I heard there are some kinds of experts in these things. But hey, it doesn't seem that difficult. They must be con-men. I'll not bother reading a book on databases.

  • grg (unregistered)

    That's nothing.

    At my PPOP there was a very important database where the design had relations expressed by having field names in the database.

    Let me repeat that: there were VARCHAR fields containing the names of the related field. So every lookup had to do a SELECT just to get the name of the desired column, then you had to build another SELECT referencing that column.
    Slow and bug-prone. And there were plans to someday change this, a few years down the line.

  • Steven G. Aldana, Ph.D. (unregistered) in reply to Brian B
    Brian B:
    This just goes to show once again that if you're "programming" by copying, pasting, and change the number on the end, you're doing something very wrong.
    Or you're using COBOL.
  • (cs) in reply to bd
    bd:
    TRWTF is that databases don't support array fields.
    What the heck do you need array fields for in a relational database?
  • SoonerMatt (unregistered)

    I wish I could give everyone a screen shot of what I am working on. Anyway we have to support and app the was written in vbasic/access. It has the tblXXXX format and none of the data is normalized.

    (It's really a gem that stands out in our enterprise oracle rac setup)

    This particular article hit home on several levels.

  • Cowards Anonymous (unregistered) in reply to T
    T:
    A Nonny Mouse:
    264 columns? is it just me, or shouldn't the developer around the 20, 50, 100, 150 etc marks be thinking "there has to be a better way"
    He or she may have used a loop to create the columns.

    I doubt anyone capable of dreaming up a design like this had the sense of logic to create a loop. I'm thinking someone spend their morning ctr+c/ctrl+v ing..

  • (cs) in reply to T
    T:
    snoofle:
    ObiWayneKenobi:
    TEACH YOURSELF ASP
    I don't think that this has anything to do with the choice of implementation language...
    No, but with TEACH YOURSELF ... IN 24 HOURS.
    ObiWayneKenobi:
    The key point was the "IN 24 HOURS"
    Mea Culpa. I'm dealing with a whole other wtf right now (coming very shortly to a sidebar near you).
  • wisi (unregistered) in reply to grg
    grg:
    That's nothing.

    At my PPOP there was a very important database where the design had relations expressed by having field names in the database.

    Let me repeat that: there were VARCHAR fields containing the names of the related field. So every lookup had to do a SELECT just to get the name of the desired column, then you had to build another SELECT referencing that column.
    Slow and bug-prone. And there were plans to someday change this, a few years down the line.

    Just wait for things to stabilize a little...

  • Annie Nymous (unregistered) in reply to A Nonny Mouse
    A Nonny Mouse:
    T:
    A Nonny Mouse:
    264 columns? is it just me, or shouldn't the developer around the 20, 50, 100, 150 etc marks be thinking "there has to be a better way"
    He or she may have used a loop to create the columns.

    okaaayyy.. but if they had to resort to this "loop" trickery you speak of to generate their columns, shouldn't they have been thinking "there has to be a better way"

    He or she may have used a script to generate the loop.

  • (cs)

    "There were several problems with this set up,"

    I disagree...The setup is THE problem.

  • oldie (unregistered) in reply to grg
    grg:
    That's nothing.

    At my PPOP there was a very important database where the design had relations expressed by having field names in the database.

    Let me repeat that: there were VARCHAR fields containing the names of the related field. So every lookup had to do a SELECT just to get the name of the desired column, then you had to build another SELECT referencing that column.
    Slow and bug-prone. And there were plans to someday change this, a few years down the line.

    I'd just like to be the FIST!!!1!!111! to point out that the word "Relational" in "Relational Database" does not have anything to do with relationships between tables.

  • jfruh (unregistered) in reply to Jithu2k1

    When you're tipping over a jug full of liquid and letting that liquid flow out, thanks to gravity, you're pouring.

    When intently studying terrible database design, you're poring.

  • (cs) in reply to bd
    bd:
    TRWTF is that databases don't support array fields.
    Thanks to Darren Sargent, we have what appears to be the first PL/SQL post. And that comes as quite a shock to me, considering all of the absurdly stupid things you can do with Oracle.
  • iogy (unregistered) in reply to A Nonny Mouse
    A Nonny Mouse:
    264 columns? is it just me, or shouldn't the developer around the 20, 50, 100, 150 etc marks be thinking "there has to be a better way"

    i'm flabbergasted

    100? 150? No, let's go directly to warp 9 and complain about 4000 not being enough.

    http://developers.slashdot.org/comments.pl?sid=572807&cid=23645679

  • Sting (unregistered) in reply to A Nonny Mouse

    You'd think so wouldn't you?

    Some time ago an ex-colleague came to me, complaining about the limitations of the database-system we used at that time (dataflex anyone?)

    It was an application for subsidies with very little data, so I wondered why the 256 fields (yup) were not enough.

    And like this setup, I soon found the problem.

    Child1Name, Child1BirthDate, ... Child2Name, Child2BirthDate, ... ... Child5Name, Child5BirthDate, ...

    And the same with

    SpouseName, SpouseBirthDate, ...

    And so on.

    The one-table-database design-pattern would have been sound where it not for that pesky customer daring to have more than 5 children, leading to the 'TableOutOfColumnsException'.

    At least with months you are certain not to have more then 31 days.

    Or 35, whatever.

  • troels (unregistered)

    Way to go Alex. You just gave me a headache. Shame on you.

  • Jean Naimard (unregistered)

    The worst project I ever worked on was a dBase system, which tallied daily, weekly and monthly statistics. This was 25 years ago.

    Since the system was sooooo slooooow, I had to keep separate tables for weekly and monthly totals, all of which had to be updated whenever you the daily values changed (such as when they were collected about 20 times per hour, for example).

    I had to go throough this rigmarole because the boss wanted to see how ALL the stats (yes, even the yearly) would change in (almost) real time.

    Needless to say, this left a very bitter and sour taste in my mouth about dBase, which wasn’t erased even when Foxbase came along, and was fast enough to allow the application to run fast enough (on a blazing fast 16mhz 386!) without weekly/monthly/yearly intermediate tables.

    So you can guess that when I discovered SQL 15 years later, it was a total revelation!!!

    CAPTCHA: feugiat

  • MrsPost (unregistered)

    I have to sob right along with the OP of the story.

    Our timesheet application doesn't support anything besides a flat table. That's right - every field in the form has to have a corresponding field in the table.

    So in very similar fashion we have fields for time in, lunch out, lunch in, etc.

    It's very sad.

  • iogy (unregistered) in reply to Sting
    Sting:
    Some time ago an ex-colleague came to me, complaining about the limitations of the database-system we used at that time (dataflex anyone?)

    I like to call the approach "perpendicular tables".

  • Michael (unregistered) in reply to ObiWayneKenobi
    ObiWayneKenobi:
    Just several problems?

    Don't you love these kinds of applications? Probably written by some idiot who picked up a TEACH YOURSELF ASP IN 24 HOURS book (and the same with SQL) and got right to work hacking away.

    And - the scary part for someone like myself, who hosts application trash like that for a living, is that the same person who wrote the above crud is the person who secured the application against SQL injection, XSS, etc.

    Web application programming is in a truly pathetic state. Put a monkey in front of a keyboard, wait a week and deploy it.

  • (cs)

    Im hazarding a guess that he could have developed in Sharepoint 2007 and tried to build a webpart for how Sharepoint handles data as lists.

    Anyway, just grumbling about my office's system that runs on great plains which we often call - Great Pain's Software

  • (cs)
    was hired to do extend and maintain... half an hour of pouring over... the overtime fields (those ending in OT1 and OT2) and the Special day (sd) were been added... the originally developer...
    Here you go, Alex... a little help for you.
  • (cs)
    As you scrolled past the 264 columns, you may have noticed "fld_TS_d35sd"...
    No, I haven't. I just passed out.
  • (cs) in reply to FredSaw
    FredSaw:
    Here you go, Alex... a little help for you.
    I find the munged italics and quotes following "Strunk and White's" to be deliciously ironic.

    But hey, it's a wiki, I can fix it. Look at this old version of the page if you want to see what I'm talking about.

  • SaumonAgile (unregistered) in reply to Sting
    Sting:
    (dataflex anyone?)
    I still have nightmares about an application partly written in dataflex. The guy in charge wrote a complete parser for a custom XML-like language.

    This application holds a fair share of WTFs in itself and the C++ server built on top of that was pretty scary too. All business entities were storing their attributes using a string object (written from scratch) containing a XML-like representation of the data. Every getter and setter was in fact a strstr into the string object... And every object could also store a list of itselfs. It was such a pain to explain to interns...

    Finally, the clever XML was designed to remove every empty tag and every tag with a 0 value.

  • John (unregistered)

    Sweet Jesus, that's awful.

    See, this is why I like reading TDWTF - it makes my personal daily WTFs seem downright ingenious. Except for MFD.

  • rgro (unregistered) in reply to bd

    ouch! You really don't need arrays in a database.

  • (cs)
    Richard Grieco (dchbg_*)
    Hah! You made me look!
  • rgro (unregistered) in reply to rgro
    rgro:
    ouch! You really don't need arrays in a database.

    I must not forget to quote when I answer. I must not forget to quote when I answer. I must not forget to quote when I answer. I must not forget to quote when I answer. I must not forget to quote when I answer. I must not forget to quote when I answer. I must not forget to quote when I answer. I must not forget to quote when I answer. I must not forget to quote when I answer. I must not forget to quote when I answer.

    Got the Bart-feeling

  • Ben4jammin (unregistered) in reply to catatoniaunlimited
    catatoniaunlimited:
    Im hazarding a guess that he could have developed in Sharepoint 2007 and tried to build a webpart for how Sharepoint handles data as lists.

    Anyway, just grumbling about my office's system that runs on great plains which we often call - Great Pain's Software

    Yea...we also have Great Pains...version 8 which is about to be upgraded to "Dynamics 10". But it will always be Great Pains to us...or in this case 10 Great Pains. And as an added bonus, Sharepoint will be part of the upgrade.

  • silent d (unregistered) in reply to iogy
    iogy:
    Sting:
    Some time ago an ex-colleague came to me, complaining about the limitations of the database-system we used at that time (dataflex anyone?)

    I like to call the approach "perpendicular tables".

    Yes, its obvious a single table with 365 columns (oops, make that 366) would have been a better design.

    Better yet, a table with one row, and 6 or 7 new columns added daily to accommodate today's data. What could go wrong?

  • k (unregistered)

    I never know whether to laugh or cry over the database WTFs. Especially when I encounter them in real life.

    Sigh. I am actually pretty good at DB design - possibly got a slight over-normalising tendency, but I have learned when to slap myself sensible. But I do wonder how to sell that when it seems so many people just wouldn't be able to tell...

  • (cs) in reply to bd
    bd:
    TRWTF is that databases don't support array fields. We all know from previous articles that every time you see bunch of variables with names containing numbers in a sequence, you can refactor all that into a single array.
    Except I wouldn't think about using arrays in a relational database, as it is a 1st normal form! If you got "array" attributes, well, that's a 1:n relation, and you store that in a related table.

    Anyway, these "clever" WTF tables are usually the product of people who think that DB tables equate to SpreadSheets!

  • (cs) in reply to grg
    grg:
    Let me repeat that: there were VARCHAR fields containing the names of the related field. So every lookup had to do a SELECT just to get the name of the desired column, then you had to build another SELECT referencing that column. Slow and bug-prone. And there were plans to someday change this, a few years down the line.

    You think that's bad, at my last job I inherited (and summarily replaced) a database structure where all of the relationships were stored in a single table! So if you had tables "foo" and "bar", you would go to this third miraculous table and find all of the records with the VARCHAR field "fooToBar" and then find the two corresponding IDs in the other two fields.

    In a couple of cases, there would not only be a "fooToBar", but also "barToFoo". That's when my head really began to spin.

  • (cs)

    Jeff Atwood needs to see this and he'll never question normalization again

  • Pony Gumbo (unregistered)

    This is nothing. As soon as these guys stop paying me, I'm going to have so many contributions to this site.

  • Tim (unregistered)

    Not to be mean, I love this site, but is anyone proofreading the entries? There were quite a few errors in that entry.

Leave a comment on “tblTimesheet”

Log In or post as a guest

Replying to comment #:

Log Out

« Return to Article