Database change documentation

Question

Post reply

Database change documentation

DCS_JJW

Valued Member

Points: 58
More actions
March 6, 2017 at 9:21 am

#328167

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!
October 16, 2017 at 5:12 am

This was removed by the editor as SPAM
December 25, 2017 at 11:14 pm

This was removed by the editor as SPAM
July 21, 2020 at 12:43 pm

This was removed by the editor as SPAM

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

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

Jeff Moden SSC Guru Points: 1003863 More actions · Answer 1

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.

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)

Jeff Moden SSC Guru Points: 1003863 More actions · Answer 2

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.

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)

Steve Jones - SSC Editor SSC Guru Points: 734449 More actions · Answer 3

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