Home/ Questions/Q 3977026
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-05-20T04:52:28+00:00

At the financial company I work at there are various separated deployment environment, including

  • 0

At the financial company I work at there are various separated deployment environment, including a staging and production environment. The data exposed by the databases of these environments can be modified using an in-house developed application. Currently, such data modification can be applied to staging and production by anyone with the appropriate access rights. Auditing compliancy, however, requires that key personnel accepts changes within the staging environment, thereby pushing it to the production environment.

To achieve this we will provide this key personnel with a user interface, in which they can see the differences between a staging and production table and accept them at the press of a button.

---------    synch    ------------
|Staging| ----------> |Production|
---------      ^      ------------
               |
   Acceptance by key personnel

My question is: how would one best determine and/or store the differences between the two environment tables such that they can be pushed to production and (optionally) reverted when not accepted? So far I came up with two solutions: (1) compare two tables (or views of those tables) using sql scripts or tooling like Red Gate’s SQL Data Compare, or (2) store changes made to the staging table as diffs, similar to diffs used by version control systems.

For both solutions I have thought of various implications, which I will not mention in this question, as I do not want to steer your thought process too much.

Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team

    I would go with Red-Gate SQL Data Compare which I have been using successfully before in scenarios like you describe. Given SQL Data Compare you can easily create SQL-scripts that work in both directions (apply and remove). A nice SQL server feature to use is to create snapshots to compare towards (available in developer and enterprise editions).

    However there are some issues that I run into:

    • If the staging and production environments are not 100% equal data wise for the set of tables you need to stage, it all gets complicated. For example if the staging environment only contains a subset of the production data. Then some kind of additional logic is needed. Removal of the data becomes more complicated as well.
    • I find that some kind of help to keep track of what has been applied is of essence. Here could a tool like Liquibase be used. The main reason is to keep track of the version of schema as well as static data in the database.
    • 0