Is it always better to redo a database, when upgrading an application?

  • Today's editorial (Modern Development) got me thinking about a related topic, but I didn't want to detract from that discussion, so I'm asking here. I work in a large state department. We've got hundreds of applications and I think hundreds of databases. Over the last 6 years I've seen 8 projects started, all using an existing database. In every case either my boss or other supervisors at that level have always started by redesigning the database. All our databases are home-grown, probably having started as MS Access databases that outgrew Access and were "upgraded" to SQL Server at some point. Sometimes I wonder if re-engineering the database is always necessary. In particular one such app has a database whose design I think is good. Not great, but good. At least well designed third normal form. But that doesn't matter, it's always the case that my boss will open TOAD and start redesigning the database.

    Is it always necessary to do that?

    Kindest Regards, Rod Connect with me on LinkedIn.

  • I would say that depends on the scope of the upgrade and what the problems are the upgrade is supposed to solve.  Upgrading shouldn't be used as an excuse to redesign the database just because.

  • You haven't mentioned as to whether or not the redesigns are somehow better when all is said and done.

    Personally, I'd just ask the boss.

    --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)

  • No.

    But it all depends if a new version functionally implements a functionallity your application may need or benifits from.

    Keep in mind some of the new stuff in databases have been put in the engine to "have it".

    It's not because your engine "has it" or is able to do it, that you should actually use it! ( as it is not guaranteed to be the best performing solution for a given problem. e.g. the format function, xquery, json, clr may bite you in the back )

    But - on the other hand - it is a good thing your management is at least validating stuff to obtain improvement.

    Johan

    Learn to play, play to learn !

    Dont drive faster than your guardian angel can fly ...
    but keeping both feet on the ground wont get you anywhere :w00t:

    - How to post Performance Problems
    - How to post data/code to get the best help[/url]

    - How to prevent a sore throat after hours of presenting ppt

    press F1 for solution, press shift+F1 for urgent solution 😀

    Need a bit of Powershell? How about this

    Who am I ? Sometimes this is me but most of the time this is me

  • Always? Every time? Hell no.

    Frequently? Yeah, probably. If you're doing new or different functionality, then it's probably a good idea to have different structures to appropriately support that functionality. That's not saying it's always appropriate, but it's probably frequently appropriate.

    "The credit belongs to the man who is actually in the arena, whose face is marred by dust and sweat and blood"
    - Theodore Roosevelt

    Author of:
    SQL Server Execution Plans
    SQL Server Query Performance Tuning

  • Jeff Moden wrote:

    You haven't mentioned as to whether or not the redesigns are somehow better when all is said and done.

    Personally, I'd just ask the boss.

     

    Well everything matches the new official company font and color scheme so it's better right?

  • Jeff Moden wrote:

    You haven't mentioned as to whether or not the redesigns are somehow better when all is said and done.

    Personally, I'd just ask the boss.

    I thought I had. Well, I'll cover it again in more detail. In some cases, the redesign does improve. Other times, IMO, it doesn't add anything improvements. Because we have so many databases, there's a lot of variety. Some of them are just a few tables with hundreds of columns in each table. They're not normalized at all. They're little more than Excel spreadsheets in a SQL Server database. But in other cases, I get the feeling like it's just rearranging chairs.

    Kindest Regards, Rod Connect with me on LinkedIn.

  • Grant Fritchey wrote:

    Always? Every time? Hell no.

    Frequently? Yeah, probably. If you're doing new or different functionality, then it's probably a good idea to have different structures to appropriately support that functionality. That's not saying it's always appropriate, but it's probably frequently appropriate.

    That is a good point, Grant, and one I haven't paid much attention to. Frequently we upgrade some old software solution that was written by someone who had some experience at writing MS Access apps. And in many cases the users don't want additional functionality, because they're used to their processes. This does give us the benefit of having the data in a SQL Server database, where it can be backed up, etc. Whereas those Access databases are scattered about on people's machines or maybe put on a network share somewhere. But in some cases, we do add new functionality. Yeah, that makes sense then to consider a better database design or at least augment it.

    Kindest Regards, Rod Connect with me on LinkedIn.

  • Rod at work wrote:

    Jeff Moden wrote:

    You haven't mentioned as to whether or not the redesigns are somehow better when all is said and done.

    Personally, I'd just ask the boss.

    I thought I had. Well, I'll cover it again in more detail. In some cases, the redesign does improve. Other times, IMO, it doesn't add anything improvements. Because we have so many databases, there's a lot of variety. Some of them are just a few tables with hundreds of columns in each table. They're not normalized at all. They're little more than Excel spreadsheets in a SQL Server database. But in other cases, I get the feeling like it's just rearranging chairs.

    I answered early and didn't see any suggestion of an actual improvement in your original post.

    In light of what you just said, I again suggest just asking the boss.  I wouldn't argue with the boss about their answer, though.  It's their shop.  You'll just know and, perhaps, can offer to help in the redesign to make some actual improvements.

    --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)

  • I might do that. I confess I've reached a point where I've learned not to ask. Asking tends never to get an answer, only stares. So, learn helplessness.

    Still, I'd like to know what reason he'd give, if any.

    And thank you for the reminder that no matter what it's my boss's call concerning always redesigning the database.

    Kindest Regards, Rod Connect with me on LinkedIn.

  • Rod at work wrote:

    I might do that. I confess I've reached a point where I've learned not to ask. Asking tends never to get an answer, only stares. So, learn helplessness.

    Still, I'd like to know what reason he'd give, if any.

    And thank you for the reminder that no matter what it's my boss's call concerning always redesigning the database.

    Yeah... I learned the latter early in my career even before SQL.  I think that lesson has saved me a couple of times by suppressing the urge to say my real feelings about the decision. "To let people see it your way, you sometimes have to give them the opportunity to fail their way".

    Of course, if it's illegal, immoral, or will hurt the company, then something more needs to happen, but one needs to make awfully damned sure of what's happening.

    --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)

  • This was removed by the editor as SPAM

  • This was removed by the editor as SPAM

Viewing 13 posts - 1 through 12 (of 12 total)

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