Sign in
 

none
Where are the designers of the disaster databases?

 > 

    Question

  • Question
    Sign in to vote
    0
    Sign in to vote

    Nobody ever comes to this forum and claims: "I designed this disaster database".

    Who comes on the forum is a developer: "I know it is bad design. I did not do it. I just have to live with it. It is in production, I cannot change it".

    Who designs these disaster or semi-disaster databases?

    In my experience reluctant developers because project wants to save money by not hiring a professional database designer.  First the reluctant-developer-design worked when tables were small. Then, as table sizes increased, eternal sequence of performance hits, day & night, even bringing down the website.

    What is your take? Thanks.

    Kalman Toth Database & OLAP Architect sqlusa.com
    New Book / Kindle: Pass SQL Exam 70-461 & Job Interview: Programming SQL Server 2012



    Saturday, July 27, 2013 5:17 PM
    |
    Moderator

All replies

  • Question
    Sign in to vote
    1
    Sign in to vote
    In my experience those databases were not designed. People just got things to work the best way they could and often given few resources. With no background in database design many of them get the job done very well.

    Tom G.

    Saturday, July 27, 2013 5:55 PM
    |
  • Question
    Sign in to vote
    0
    Sign in to vote

    > With no background in database design many of them get the job done very well.

    How did they do it?

    I can imagine if you a smart developer and worked on a well-designed database, you can design along the same lines.  For example, you can just mimick the design principles of AdventureWorks2012.

    Kalman Toth Database & OLAP Architect sqlusa.com
    New Book / Kindle: Pass SQL Exam 70-461 & Job Interview: Programming SQL Server 2012


    Saturday, July 27, 2013 8:28 PM
    |
    Moderator
  • Question
    Sign in to vote
    1
    Sign in to vote
    Our company Isah develops and sells its own ERP system Isah. It started more than 25 years ago in clipper with just a few tables. These days it is an MS SQL Server database with around 1.000 tables, 1.000 triggers, 5.000 stored procs and so on. We have 2.500.000 lines of database source code and 4.500.000 lines of client source code. Things just tend to grow. Also, best practices change. I can still recognize the first Clipper tables. Also, after that, we had a period in which normalizing the database was the credo. These days, having some redundancy to enhance performance is not thought off as a big design flaw. The only problem is that refactoring and redesign doesn't happen as often as I would like. The management prefers new modules that they can add to the price list over better and easier maintainable code. But I am whining, since we still get some percentage of our time to do refactoring or research other architectures (like adding a middle tier and web GUIs).

    • Edited by Chris Sijtsma Sunday, July 28, 2013 8:02 AM comma added
    Saturday, July 27, 2013 10:22 PM
    |
  • Question
    Sign in to vote
    1
    Sign in to vote
    Hi Kalman,

    Yes, I’m agree with your option:

    In my experience reluctant developers because project wants to save money by not hiring a professional database designer.  First the reluctant-developer-design worked when tables were small. Then, as table sizes increased, eternal sequence of performance hits, day & night, even bringing down the website.

    I think this is an open discussion as different companies may have different organization structure, for example, with a small company, the application developer may be also the database administrator, all databases are designed and manipulated by himself/herself; a big company has a different picture, product design team, application developer team and database administrator team will work together to get the final database structure. Regarding to the following concern:

    Who comes on the forum is a developer: "I know it is bad design. I did not do it. I just have to live with it. It is in production, I cannot change it".

    I think this occurs more likely when he/she took over an old project and he/she don’t have permission to change the original database, table structures. Under this situation, to find a way to fix the current problem under the original structure is what we can do.

    Allen Li
    TechNet Community Support

    Monday, July 29, 2013 3:17 AM
    |
    Moderator