Post reply

Packaged-Application Database Nightmares - A Horror Story.

  • December 21, 2015 at 10:38 pm

    #303395

    Comments posted to this topic are about the item Packaged-Application Database Nightmares - A Horror Story.

  • December 22, 2015 at 3:19 am

    #1847372

    So very familiar :laugh:

    Happily the happy ending came about as well.

  • December 22, 2015 at 4:28 am

    #1847382

    Great story

  • December 22, 2015 at 4:57 am

    #1847387

    It's reality. Our stories.

  • December 22, 2015 at 6:02 am

    #1847409

    Thought I might have heard a ghostly voice whisper 'ORM ... ORM' at some point in there.

  • December 22, 2015 at 6:33 am

    #1847420

    Thanks for the story. Haven't experienced anything quite that bad.

  • December 22, 2015 at 7:13 am

    #1847436

    You had me up until the point when management began listening to the DBA. After years of being proved right in the end, I still have to fight with management to make sure things are designed correctly UP FRONT. And still often lose the fight until once again I am proven right in the end. <SIGH>

    Gordon Pollokoff

    Wile E. is my reality, Bugs Bunny is my goal - Chuck Jones
    Walking on water and developing software from a specification are easy if both are frozen. - E. Berard
    Doing more things faster is no substitute for doing the right things. - S. R. Covey
    Any sufficiently advanced bug is indistinguishable from a feature.- R. Kulawiec

  • December 22, 2015 at 7:23 am

    #1847442

    After reading just the first section "The Horror Begins", I thought you were talking about a Microsoft Dynamics application. With a slight bit of exaggeration added, just slight. I am the BI developer of one of these older Dynamics packages. I am glad to hear it is a (semi-)fictional story.

    Dan Beggs

  • December 22, 2015 at 9:35 am

    #1847487

    From the article:

    This horror story is fictionalized...

    Heh... no it's not. It almost perfectly describes what I've been through twice and am still trying to pick up the pieces. 😛

    --Jeff Moden

    RBAR is pronounced "ree-bar" and is a "Modenism" for Row-By-Agonizing-Row.
    First step towards the paradigm shift of writing Set Based code:
    ________Stop thinking about what you want to do to a ROW... think, instead, of what you want to do to a COLUMN.

    Change is inevitable... Change for the better is not.

    Helpful Links:
    How to post code problems
    How to Post Performance Problems
    Create a Tally Function (fnTally)

  • December 22, 2015 at 9:56 am

    #1847497

    I'd love to start a centralized wall of shame website for vendors that deploy databases this way.

  • December 22, 2015 at 10:23 am

    #1847510

    Tears of joy fill your eyes are you are looking at a perfectly designed fourth-normal-form diagram!

    hmm... I would be skeptically cautious about a database implemented completely in perfect fourth-normal-form. Once the business starts demanding reports run against this database, and doesn't want to spend the time to do a data warehouse, this will quickly become the bane of that DBA's existence. Converting developers to your line of thinking is easier than converting business people.

  • December 22, 2015 at 10:29 am

    #1847512

    Chris Harshman (12/22/2015)

    SQLBlimp Wrote:Tears of joy fill your eyes are you are looking at a perfectly designed fourth-normal-form diagram!

    hmm... I would be skeptically cautious about a database implemented completely in perfect fourth-normal-form. Once the business starts demanding reports run against this database, and doesn't want to spend the time to do a data warehouse, this will quickly become the bane of that DBA's existence. Converting developers to your line of thinking is easier than converting business people.

    Agreed. In the modern era, the business should (but often does not) consider a data warehouse as part of the original deployment. I hate reports running against OLTP.

    Thanks

    John.

  • December 22, 2015 at 10:51 am

    #1847517

    The introduction of the story albeit far-fetched it's some sort of a reality in some places.

  • December 22, 2015 at 11:18 am

    #1847527

    I sincerely wish I could hypothesize that a script failed to run somewhere in the installation, but my personal experience is that most current database systems are forced to be designed to minimize the risk of poorly developed and tested code with the goal of avoiding maintenance and support problems.

    A good DBA can make the appropriate modifications for accuracy and performance, but at great personal risk of criticism if such changes cause application code issues.

    The last ten years of my forty-two years in IT saw a change away from accuracy of data and performance to total emphasis on 'up time', even when the data that was required to be available was total inaccurate.

    At one company, it was even dictated to IT by owners that users be allowed to enter their data regardless of accuracy based on the assumption that 'close is good enough' and 'somebody will fix it later'. This meant that engineering designs normally required multiple iterations of user attention to get things even close to accurate. Items in physical layouts could literally end up down the street in the next block.

    Rick
    Disaster Recovery = Backup ( Backup ( Your Backup ) )

  • December 22, 2015 at 11:25 am

    #1847531

    Please add to your bulletined list: All tables are six characters in length and use a cryptographic algorithm for the name.:-D

Viewing 15 posts - 1 through 15 (of 87 total)

You must be logged in to reply to this topic. Login to reply