• David-T (unregistered)

    I'm not really sure that a "history" feature qualifies as a WTF. The use it is being put to, perhaps, but... meh.

  • David-T (unregistered) in reply to David-T

    Actually, perhaps the real WTF is the title. I don't know, how is an Employee ID like a Writing Desk? The article doesn't say.

  • malcolm in the middle (unregistered)

    How shall I compare thee to a writing desk?

  • TheCPUWizard (unregistered) in reply to David-T

    David-T <= A "Writing desk" is where saies are formally created. Since the actual data being used is from a sales portfolio (rather than an actual fixed ID for an employee), the title does make sense (you just need some domain knowledge).

  • nerd4sale (nodebb)

    The only real WTF in this piece of code (apart from the weird business logic for the employee id), is the ROWNUM=1 clause. This indicates that either an employee id is not unique on a given date (and apparently it doesn't matter which one is returned), or it is unnecessary and should be removed.

  • Pjrz (unregistered) in reply to David-T

    I believe its a reference to Lewis Carroll's Alice in Wonderland. The question "Why is a raven like a writing desk" is asked by the Mad Hatter (?), with no expectation of a sensible answer.

    Absolutely no idea what this has to do with the actual article though!

  • Pjrz (unregistered) in reply to David-T

    I believe its a reference to Lewis Carroll's Alice in Wonderland. The question "Why is a raven like a writing desk" is asked by the Mad Hatter (?), with no expectation of a sensible answer.

    Absolutely no idea what this has to do with the actual article though!

  • Pjrz (unregistered)

    Also have no idea why my post appeared twice. The first time I submitted I got a Captcha error (how can I get an error when all you need to do is tick a box?). So I ticked and submitted again. Then I got two posts implying the submission with an error worked anyway. :)

  • Futuro (unregistered)

    "Artie was ready to solve that problem, though, as he quickly added the EFFECTIVE_START_DATE and EFFECTIVE_END_DATE fields. Instead of updating rows as portfolios moved around, you could simply add new rows, keeping an ongoing history of which employee held which portfolio at any given time."

    Looks like Artie has just "invented" Event Sourcing. Not really a WTF, more a "man-ahead-of-his-time". Go Artie!

  • comments.Count.ToString + "th" (unregistered)

    Why they didn't update the UI with some basic validation, to rule out the most regular ways users corrupt the data, that is the real WTF.

  • Shoreline (nodebb)

    People keep asking what the article has to do with the title.

    Let me ask you this: if an application where you need to look for employees has no employee table, what colour are the bears?

  • DQ (unregistered) in reply to Shoreline

    42

  • Jon (unregistered)

    An employee_ID is like a writing desk because neither of them are case sensitive.

    So AND employee_id = EMPLOYEE_ID is always true. Which is possibly why they added in the rownum restriction, because without the actual employee restriction you probably would get a lot of rows back even if there were no overlapping dates in the data.

  • Ya .... (unregistered) in reply to David-T

    Without knowing the business requirements, where is the WTF?

    It looks like Arty took a use case or use cases and came up with a solution for the specific problem.

    The concept of portfolios actually makes a lot of sense since they can be juggled around.

    Maybe the solution isn't perfect but I don't know the whole story.

  • Dmitri (unregistered) in reply to comments.Count.ToString + "th"

    Most likely UI sources were lost many years ago.

  • Raj (unregistered)

    This is basically a type 2 slowly changing dimension. Looks like Artie knows more about databases than the person who wrote the article.

  • Sole Purpose of Visit (unregistered) in reply to Pjrz

    Indeed. (Feel free to Google it, although I am smug enough to know the original answer.)

    When Lewis Carroll posed the question, he did so with the deliberate intention of not providing an answer, because there really isn't one. I expect this was a bit of a first for Victorian readers, because the Victorians absolutely loved wordplay, and would definitely have expected an answer.

    Carroll's ex post facto answer was pretty weak, imo. However, there have been competitions to produce one since. My three favourites (continuing with the theme of wordplay) are:

    • because one has flapping fits and the other fitting flaps

    • because a writing desk is a rest for pens and a raven is a pest for wrens

    • because (Edgar Allen) Poe wrote on both

    The third one (from the puzzle fiend Sam Lloyd) is my favorite, if only for the very silly pun, but the second probably fits the OP best, because it is totally contrived and doesn't really answer the question. Much like the schema for this database.

    Me, I think this is a wonderful title. Gor bless ya, Remy!

  • Sole Purpose of Visit (unregistered) in reply to Ya ....

    I don't think you encode the concept of a portfolio in a string, let alone what appears to be a primary key. I think you express it as another table (or more, depending upon the level of normalization) and adjust the schema accordingly.

    But, hey, I don't design databases for a living. Apparently neither should Artie.

  • Pietro Gagliardi (andlabs) (unregistered) in reply to Ya ....

    Sure, but in that case, why isn't there two separate tables, one for employees with permanent IDs and one for portfolios with a relation to the employee that has the portfolio (at that time, if you want to include historical data)? In fact, this is the actual WTF: this table is an amalgam of two separate concepts that should be independent data tables, and will have bad consequences for anyone wanting to do employee management.

    This database doesn't really store anything about individual employees: how can you tell if an employee has no portfolio and isn't just fired? Is there a program that can tell if an employee has been fired? Is some manager getting daily automated emails asking why Artie has had no portfolios for 15 years?

    The current system will also break if this firm ever hires someone with the same name as a former employee... "Hey Bob, you just got us our biggest deal in 10 years, but according to our database, when you were 3 years old, you lost us $100M in a junk portfolio; we have to let you go, which I thought we did the first time, so now I have to see who the idiot in HR is..."

    (This comment also addressed to the other people wondering what the WTF is in portfolio history management.)

  • Andrew K. Setter (unregistered) in reply to Pjrz

    Found the real WTF... :)

  • I Am A Robot (unregistered) in reply to Pjrz

    Because Poe wrote on both of them.

  • Steve The Mob Boss (unregistered) in reply to Shoreline

    White. That's the answer to every puzzle that ends "What colour are the bears?".

  • Sole Purpose of Visit (unregistered) in reply to Pietro Gagliardi (andlabs)

    That explanation, I think, wins the thread.

    Perfect.

  • Dude (unregistered) in reply to Shoreline

    Purple, because aliens don't eat pancakes.

  • Chris D (unregistered)

    So this is actually my WTF. To answer why there aren't separate tables for this, it boils down the environment at the time. The Director at the time (who was in charge for roughly 13 years) didn't believe in system architecture, refactoring, or that 2 programmers might have different skillsets. This monstrosity was thrown together with a "make it now, doesn't matter how bad it is" attitude.

    To answer why we haven't torn it out and replaced it, we don't have the source code for the core product or the management UI. The original vendor owns it, and refused to give it to us when we ended the mess of a contract we had with them. So we don't have the source code for the core system, and we don't have the home-grown C++ compiler they used. As well, a million things have grown up around this table, working around its quirks. There's simply no budget or time allowed to introduce some sanity into that right now.

  • Barf4Eva (unregistered) in reply to Sole Purpose of Visit

    lol, funny answer

  • Decius (unregistered) in reply to David-T

    "How is an Employee ID like a Writing Desk?" "Both are flammable"

  • Foo AKA Fooo (unregistered) in reply to Decius

    Actually, they're inflammable!

  • foxyshadis (unregistered) in reply to Chris D

    The idea of dumping the contract for the ERP system your company runs on, but continuing to use it with no plans to ever replace it, is mind-boggling. They've basically bet the future of the company on the hope that no business process will ever change, or else everyone slowly reverts back to Excel and other kludges until the ERP system is completely ignored.

  • Sigh (unregistered)

    I am working on something really similar... People really should be less trustful in this industry, none of us saw it coming when the new hire senior developer was assigned to this project alone. We were appalled to see the code for the first time after he just stopped coming to the office for two weeks without any notice...

  • cheong (nodebb)

    Bitten by similar issue, except it's not for sales portfolio, but past wage record for pension calculation.

    Who decided reusing staff ID is a good idea is the real WTF.

  • Mike (unregistered)

    they're not re-using the employee_ids after someone terminates, are they?

Leave a comment on “How is an Employee ID like a Writing Desk?”

Log In or post as a guest

Replying to comment #:

« Return to Article