Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    primarykey
    data
    text
    <p>Within our team, we handle database changes like this:</p> <ul> <li>We (re-)generate a <strong>script</strong> which creates the <strong>complete database</strong> and check it into version control together with the other changes. We have 4 files: tables, user defined functions and views, stored procedures, and permissions. This is completely automated - only a double-click is needed to generate the script.</li> <li>If a developer has to make changes to the database, she does so on her <strong>local db</strong>.</li> <li>For every change, we create <strong>update scripts</strong>. Those are easy to create: The developer regenerates the db script of his local db. All the changes are now easy to identify thanks to version control. Most changes (new tables, new views etc) can simply be copied to the update script, other changes (adding columns for example) need to be created manually.</li> <li>The <strong>update script is tested</strong> either on our common dev database, or by rolling back the local db to the last backup - which was created before starting to change the database. If it passes, it's time to commit the changes.</li> <li>The update scripts follow a <strong>naming convention</strong> so everybody knows in which order to execute them.</li> </ul> <p>This works fairly well for us, but still needs some coordination if several developers modify heavily the same tables and views. This doesn't happen often though.</p> <p>The important points are:</p> <ul> <li>database structure is only <strong>modified by scripts</strong>, except for the local developer's db. This is important.</li> <li><strong>SQL scripts are versioned</strong> by source control - the db can be created as it was at any point in the past</li> <li><strong>database backups</strong> are created <strong>regularly</strong> - at least before making changes to the db</li> <li>changes to the db can be done quickly - because the scripts for those changes are created relatively easily.</li> </ul> <p>However, if you have a lot of long lasting development branches for your projects, this may not work well.</p> <p>It is by far not a perfect solution, and some special precautions are to be taken. For example, if there are updates which may fail depending on the data present in a database, the update should be tested on a copy of the production database.</p> <p>In contrast to rails migrations, we do not create scripts to reverse the changes of an update. But this isn't always possible anyway, at least in respect to the data (the content of a dropped column is lost even if you recreate the column).</p>
    singulars
    1. This table or related slice is empty.
    plurals
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. VO
      singulars
      1. This table or related slice is empty.
    1. This table or related slice is empty.
 

Querying!

 
Guidance

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload