[ASP.NET + MYSQL] ROR db:migrate voor asp.net

[Flapmo]

Ik ben op zoek naar een alternatief in ASP.net voor de db:migrate functie van RoR.

Specifieker, ik ben op zoek naar een nette oplossing om met meerdere mensen aan een project te werken, ieder met DB onder version control.

Eigen zoekacties hebben helaas niet veel nuttigs opgeleverd. Migration geeft alleen hits over het migraten van je database naar een andere versie en/of server. De enige oplossing die ik zo kan bedenken is "publish to provider" en dan de .sql file onder version control zetten. Maar dan moet je iedere keer iemands .sql executen en deze overschrijft tables. Dit is natuurlijk niet iets wat je wilt, als ik zelf een kolom heb toegevoegd en iemand anders ook dan wordt 1 vd 2 overschreven en gaat verloren.

Ik heb wat zitten prutsen met het automatisch genereren van een "change script" in "SQL server management studio" maar of dit nu werkt is onduidelijk omdat dit voorlopig nog een error geeft die ik nog niet verholpen heb.

Een nettere oplossing zou deze manier zijn gepost op stackoverflow.

Martin Fowler wrote my favorite article on the subject, http://martinfowler.com/articles/evodb.html. I choose not to put schema dumps in under version control as alumb and others suggest because I want an easy way to upgrade my production database.

For a web application where I'll have a single production database instance, I use two techniques:

Database Upgrade Scripts
A sequence database upgrade scripts that contain the DDL necessary to move the schema from version N to N+1. (These go in your version control system.) A version_history table, something like

create table VersionHistory (
Version int primary key,
UpgradeStart datetime not null,
UpgradeEnd datetime
);
gets a new entry every time an upgrade script runs which corresponds to the new version.

This ensures that it's easy to see what version of the database schema exists and that database upgrade scripts are run only once. Again, these are not database dumps. Rather, each script represents the changes necessary to move from one version to the next. They're the script that you apply to your production database to "upgrade" it.

Developer Sandbox Synchronization
A script to backup, sanitize, and shrink a production database. Run this after each upgrade to the production DB.
A script to restore (and tweak, if necessary) the backup on a developer's workstation. Each developer runs this script after each upgrade to the production DB.
A caveat: My automated tests run against a schema-correct but empty database, so this advice will not perfectly suit your needs.

Zijn er bekende nette oplossingen, ik kan mij niet indenken dat ik de enige ben met dit probleem . Dit is toch vrij standaard.

[ Voor 46% gewijzigd door Flapmo op 07-05-2009 22:38 ]