Databases
StackOverflow2013
Postsdbo
PO
 

Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    primarykey
    data
    text
    <p>Actually, this is the best way. As cumbersome as it may sound, it is better than the alternatives of using SQL Compare like tools or VSDB .schema file deployment. I have argued for exactly the smae approach for some time now: <a href="http://rusanu.com/2009/05/15/version-control-and-your-database/" rel="noreferrer">Version Control and your Database</a>. My apps deploy the v1 schema from the initial script, then run upgrade script for each version. Each script know how to upgrade from version N-1 to N, and only that. Final result is the current version.</p> <p>The biggest draw back is lack of an authoritative .sql file too look to find the <em>current</em> version of any object (procedure, table, view etc). But the advantages of being able to deploy your app over <em>any</em> previous version, and the advantage of deploying by well controlled and tested <em>scripts</em> far outweigh the drawback.</p> <p>If you feel bad for using this deployment process (script to deploy v1. then apply v1.1, then v1.2 ... until finally you apply v4.5, current) then keep this in mind: exactly the same process is used by SQL Server internally to upgrade the database between releases. When you attach an older database, you see the famous 'database is running the upgrade from version 611 to 612' and you see that the upgrade goes <em>step by step</em>, does not upgrade straight to current version 651 (or whatever is current in your case). Nor does the upgrade runs a diff tool to deploy v 651 over v. 611. That is because the <em>best</em> approach is the one you just use, upgrade one step at at time.</p> <p>And to add an actual answer to your question, after posting a rather oblique rant (Is a topic I have strong opinions about, can you tell?): I think is valuable to have a scripted version of the current version, but I think it should be a contiguous integration build process deliverable. In other words, your build server should build the current database (using the upgrade scripts) and then, as a build step, script out the database and produce a build drop with the current version schema script. But those should be only used as a reference for searching and code inspection, not as a deployment deliverable, my 2C.</p>
    singulars
    1. This table or related slice is empty.
    1. PODatabase Change Management - Setup for Initial Create Scripts, Subsequent Migration Scripts
      singulars
      1. PTQuestion
    1. PTAnswer
    1. This table or related slice is empty.
    1. USRemus Rusanu
    plurals
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. PODatabase Change Management - Setup for Initial Create Scripts, Subsequent Migration Scripts
      singulars
      1. PTQuestion
    1. This table or related slice is empty.
    1. VO
      singulars
      1. PO
      1. This table or related slice is empty.
      1. VTUpMod
    2. VO
      singulars
      1. PO
      1. This table or related slice is empty.
      1. VTUpMod
    3. VO
      singulars
      1. PO
      1. This table or related slice is empty.
      1. VTUpMod
    1. COI'm interested in this approach. I imagine the run time of this script will increase a lot over time. Do you eventually 'roll up' the earlier changes into the initial create script to get around this?
      singulars
      1. PO
      1. USDolbz
    2. CO@Dolbz: yes, but keep in mind that a roll-up means that you break support for certain upgrade paths. Eg. your app has reached v. 5.0 and you have upgrade scripts from 1.0, 1.1, 1.2, 2.0, 2.1 etc. You roll them up to, say, v4.0 then you cannot upgrade prior versions anymore. Workaround is to keep the old script sin place as an alternative for upgrade, or if you know for certain that there is no deployment with version prior to 4.0, deprecate the support.
      singulars
      1. PO
      1. USRemus Rusanu
    3. COYeah. good point but of course even after rolling up script you can get the original unrolled scripts back from your SCM if absolutely required.
      singulars
      1. PO
      1. USDolbz
 

Querying!

 
Guidance
A row detail

Detail views are divided into sections. All the information in the data section comes from columns in the selected row. The other sections display data from other, related rows.

Related data can be related in a to-one or a to-many fashion. Captions of data related in a to-many fashion link to a list view showing a filtered view of the table.

Try moving around until you find a non-empty to-many entry and click on the label to get to one. You can move back to the root by clicking on the database name in the header.

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