|
|
| Non-WTF Job: C++ Developer at Good Grievance (Ronkonkoma, NY) |
|
|
|
| Non-WTF Job: C++ Developer at Good Grievance (Ronkonkoma, NY) |
| « Prev | Page 1 | Page 2 | Page 3 | Next » |
|
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! |
|
"I'll leave those as an exercise for the reader to commit seppuku over."
|
|
Cool! A Stupid Database Table WTF! It's been a while since we've had one of those.
|
|
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 |
|
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.
|
|
Aaargh. Why is it that always when a truly horrible atrocity shows up on this site, it involves SQL and relational design?
|
I don't think that this has anything to do with the choice of implementation language... |
He or she may have used a loop to create the columns. |
No, but with TEACH YOURSELF ... IN 24 HOURS. |
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. |
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" |
|
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. |
Well, this one didn't involve "design" in the traditional sense. |
|
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.
|
|
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. |
Re: tblTimesheet
2008-07-23 08:59
•
by
Steven G. Aldana, Ph.D.
(unregistered)
|
Or you're using COBOL. |
What the heck do you need array fields for in a relational database? |
|
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. |
Re: tblTimesheet
2008-07-23 09:01
•
by
Cowards Anonymous
(unregistered)
|
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.. |
Mea Culpa. I'm dealing with a whole other wtf right now (coming very shortly to a sidebar near you). |
Just wait for things to stabilize a little... |
Re: tblTimesheet
2008-07-23 09:03
•
by
Annie Nymous
(unregistered)
|
He or she may have used a script to generate the loop. |
|
"There were several problems with this set up,"
I disagree...The setup is THE problem. |
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. |
|
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. |
|
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 |
|
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. |
|
Way to go Alex. You just gave me a headache. Shame on you.
|
|
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 |
|
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. |
I like to call the approach "perpendicular tables". |
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. |
|
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 |
Here you go, Alex... a little help for you. |
No, I haven't. I just passed out. |
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. |
Re: tblTimesheet
2008-07-23 10:06
•
by
SaumonAgile
(unregistered)
|
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. |
|
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. |
|
ouch! You really don't need arrays in a database.
|
Hah! You made me look! |
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 |
Re: tblTimesheet
2008-07-23 10:15
•
by
Ben4jammin
(unregistered)
|
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. |
Re: tblTimesheet
2008-07-23 10:17
•
by
silent d
(unregistered)
|
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? |
|
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... |
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! |
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. |
|
Jeff Atwood needs to see this and he'll never question normalization again
|
|
This is nothing. As soon as these guys stop paying me, I'm going to have so many contributions to this site.
|
|
Not to be mean, I love this site, but is anyone proofreading the entries? There were quite a few errors in that entry.
|
| « Prev | Page 1 | Page 2 | Page 3 | Next » |
ObiWayneKenobi:
