- 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
For the first one, that's pretty bad. A simple table of the numbers 50,1000,5000, etc..., if you need to provide values for a drop-down, should be MORE than adequate to calculate and display whatever you need .... Nice primary key on that table, as well !
As for the last one, though, it is actually very good practice to have columns like these in your lookup tables, instead of hard-coding "IF CODE=xxx" over and over in your applications and/or SQL statements. Though, it does seem that "is_standard" and "is_custom" are probably mutually exclusive and therefore redundant, but who knows? (maybe an order type can be neither?)
But, in general, adding as many attributes as possible to a lookup table and taking specific checks against specific "code" values out of your code really makes your lookup values self-documenting and your code actually shorter, more flexible, and more readable.
Admin
If it were me I'd redo the order types table to just eliminate the is_standard and is_custom fields (seems a tad redundant) Maybe even deal with the name field in code. However there may be other order types in the future and maximum discounting and/or ability to cancel flags are needed. But other than that, WTF :-)
Admin
The third example in my opinion is not worthy of a daily wtf posting. The table is not completly normalized and there may be some redundant data; however with out knowing more of the application logic and schema you really can't make a wtf judgement.
For example the code field could be fairly abstract, where the two example records we see STND and CUST are used in a current sales system. The old sales system could implement a NRML record, with a name field value of Normal Order that is_standard and is_custom and not can_cancel. The max_disc is 5 percent.
Admin
I'm still trying to wrap my tiny little primate brain around the second one. How, exactly are they getting someone's age when there's no current date...? or.. did Alex just make a typo?
Admin
I'm not sure, but I think this might be required by some foreign key constraints. Let's say you have a table called Address with a field called StateId, and it's a foreign key to a table called States. Suppose there's an address without a state (non-US maybe). You'd want to put NULL for the StateId, but maybe that would cause a violation. So you add a record to States with a description of '' (empty string) or 'Not Used', and use that for non-US addresses.
Admin
No typo. It's the lack of GETDATE() which explains why it only works in 2000 ;-)
Admin
I'm assuming these are the only two records in the table. If so, then having four fields to differentiate between Standard and Custom is slight overkill.
Sometimes it's good have stuff table-driven, but occasionally I see developers go way overboard, table-driving functionality that would never, ever change. Or if it did change, it would only be as a result of a massive overhaul of the system.
For instance, I saw a web app that had all page text stored in the database, on the off chance that we'd have a non-English speaking customer sometime in the future. Of course, that never happened. Meanwhile, adding some text to a page involved editing 3 or 4 tables, and any new developer just coming to the system would literally spend a day on just adding text to a page. Sometimes it makes more sense from a maintenance perspective to just hard-code stuff.
Admin
Or just use files on the system and a manager class. Keeping data that is primarily static and tighly coupled to the code is a WTF in itself. It makes abount as much sense as keeping the application binaries or source in the application DB.
The standard/custom table. Is this (and was intended to be) full table? If so, it's pretty stupid. The only information it really holds that isn't inherently part of the application logic is the max percent discount. And unless the code handles all four states, it makes no sense to have iscustom and isstandard which I am inclined to believe are mutually exclusive. What's a standard custom order?
Admin
Exactly I general anyone who has to maintain such a system will discover that anytime some wunderkin dreams up a new billing method or type of order you'll need to add 2 or 3 columns to hold information that the current table design doesn't and redesign all the apps that talk to that table. So what have you gained really? An ugly table you need to update along with your executables... easier to just change the executables.
Admin
I've also got to defend the order_types table as sensible. It would make it easy to change the business logic or add different order types. Yes, "is_standard" and "is_custom" might be a little much, but even then it's a pretty minor WTF.
The "Y2K" bug is a real gem, though.
Admin
that would be "Not US-ed" [:p]
Admin
Actually, NULL would do just as well for the foreign key constraints (at least in Oracle); the actual purpose might be to make joins easier, because you don't have to make outer joins when you have such dummy values.
Admin
I'm in the business of creating warehouse management systems and I've seen system with 10 or more order types, with only slight differences in the way they have to be handled.
Having fields like this makes your life much easier than writing serveral times
if (order.ordertype.equals("STND") || order.ordertype.equals("STDA") ||order.ordertype.equals("FOO") || order.ordertype.equals("BAR") ) {Even if there are currently only two ordertypes and the table seems redundant, this is the kind of programming style that makes extensions and adoptions easy in the future.
Admin
That's what makes it a WTF.
/Jakob.
Admin
While we frequently abuse NULLs to record that a value is not present or not applicable, NULL is supposed to mean unknown, which is the source of three-valued-logic. If you want an actual value there (I usually use 0, but -1 is clear as a magic value, too), and you want to keep your foreign key constraints, you have to put zero (or -1) rows in the referenced tables.
Admin
I've also seen stuff like this never extended and become another esoteric thing to understand when maintaining the code. It's impossible to predict all future needs and sometimes things that seem likely never come to be.
Instead of writing if statements all over the place, it's better, IMO, to create a layer of abstraction in the code that handles this type of detail. The initial implmentation can be an if-else if that's all that is needed at the time. If a more robust framework is needed later, it can be implemented without rewriting a lot of code. I find this has a much better success rate than trying to be clarivoyant.
Admin
With the first row in every table being NULL..... what is even more funny is that if they created all the tables first and setup the FK relationships, they actually had to WORK at it in order to do this to maintain referential integrity!!!!!
Admin
What on earth are you talking about?
Admin
That Order Type table is a WTF.
If you want to generalize it - then great - have an Order Types table and then have a Table of 'Order Rules' (Cancellable, Discount Values, etc) and M:N between types and rules.
Then its actually table driven and flexible -- if you're gonna do it, do it 100% - none of this half baked is_standard and is_custom crap - so junior. Do we also add 'is_UPS' and 'is_FedEx' for shipping methods ?
Oh - and this design would work much better if the logic is implemented in Javascript. [H]
Admin