Database change documentation

  • DCS_JJW

    SSC Rookie

    Points: 28

    I am curious about what kind of database documentation is provided to you the client (or you as a vendor to the client) when changes are made to the database? 

    We have a vendor that develops and maintains an application/database, but we do forms and reports in-house. When database changes are made, we get sql scripts and ruby code as documentation for what has changed. While we can read the sql code and can muddle through the ruby code... it's cumbersome to have to sort through 20-30 files sometimes just to understand what is changing. 

    We really expect to get a little more detail/summarization like a list of tables, columns added/dropped/updated (the change detail... such as datatype from int to bigint or varchar (10) to Varchar(250) ) and the reason why it was changed.

    If you are a vendor, what kind of documentation do you provide, for database changes, to the client if they do their own reporting as well? If your client asked for a distinct summary of changes, would you be receptive to their needs?

    If you are an end user/client.... what kind of documentation to you get/expect from the vendor, so you don't have to guess at what might break your code?

    Thanks for any feedback you might have on this!

  • This was removed by the editor as SPAM

  • This was removed by the editor as SPAM

  • Jeff Moden

    SSC Guru

    Points: 993862

    Two spam posts reported.

    --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.
    "If you think its expensive to hire a professional to do the job, wait until you hire an amateur."--Red Adair
    "Change is inevitable... change for the better is not."
    When you put the right degree of spin on it, the number 3|8 is also a glyph that describes the nature of a DBAs job. 😉

    Helpful Links:
    How to post code problems

  • Jeff Moden

    SSC Guru

    Points: 993862

    DCS_JJW - Monday, March 6, 2017 9:21 AM

    I am curious about what kind of database documentation is provided to you the client (or you as a vendor to the client) when changes are made to the database? 

    We have a vendor that develops and maintains an application/database, but we do forms and reports in-house. When database changes are made, we get sql scripts and ruby code as documentation for what has changed. While we can read the sql code and can muddle through the ruby code... it's cumbersome to have to sort through 20-30 files sometimes just to understand what is changing. 

    We really expect to get a little more detail/summarization like a list of tables, columns added/dropped/updated (the change detail... such as datatype from int to bigint or varchar (10) to Varchar(250) ) and the reason why it was changed.

    If you are a vendor, what kind of documentation do you provide, for database changes, to the client if they do their own reporting as well? If your client asked for a distinct summary of changes, would you be receptive to their needs?

    If you are an end user/client.... what kind of documentation to you get/expect from the vendor, so you don't have to guess at what might break your code?

    Thanks for any feedback you might have on this!

    It sounds to me like your vendor is being pretty lazy by not providing a summary but... I wouldn't look the gift horse in the mouth too much.  It's a rare thing when you can get change scripts out of a vendor.  Remember that that next question out of folks mouths after a change summary is provided is "Ok... any chance of seeing the change code?".

    --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.
    "If you think its expensive to hire a professional to do the job, wait until you hire an amateur."--Red Adair
    "Change is inevitable... change for the better is not."
    When you put the right degree of spin on it, the number 3|8 is also a glyph that describes the nature of a DBAs job. 😉

    Helpful Links:
    How to post code problems

  • Steve Jones - SSC Editor

    SSC Guru

    Points: 714595

    I haven't done much more than have the deployment scripts available in the past. We used to keep a "changes.txt" on the desktop of every server, where DBAs could update this whenever  they did something, but that stopped working once we rarely connected to a desktop.

    At Redgate, we have added reports to various products to help here, since we've had customers asking: https://www.red-gate.com/hub/product-learning/sql-compare/comparison-report

    Disclosure: I work for Redgate

Viewing 6 posts - 1 through 6 (of 6 total)

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