> I'll add to my own post that the conceptual/ORM approach is
> really for the structure, and won't help with the scripts
> that generate procedures, functions and such. Fundamentally,
> you'd end up with one physical schema create DDL script from
> an ORM or ERD tool, many sproc/function DDL scripts and one
> or more "dummy data" creation mechanisms.
I'd like to add to Paul's excellent analysis that migration of already
existing data has to be taken into account as well. This can give some extra problems
along the way, especially when tables are split up, constraints are added/changed etc.
To avoid a big misery, the more the model is finalized prior to development, the
better, i.e.: the more ad-hoc changes are required, the more migration issues will pop
up.
FB.
--------------------------------------------------------------------
Get LLBLGen Pro, the new O/R mapper for .NET: http://www.llblgen.com
My .NET Blog : http://weblogs.asp.net/FBouma
Microsoft MVP (C#)
--------------------------------------------------------------------
>
> _________________________________
> Paul Tiseo, Systems Programmer
> Research Computing Facility
> Mayo Clinic Jacksonville, Griffin 371
> [EMAIL PROTECTED]
> �
>
>
> > -----Original Message-----
> > From: Unmoderated discussion of advanced .NET topics.
> > [mailto:ADVANCED- [EMAIL PROTECTED] On Behalf Of
> Tiseo, Paul
> > Sent: Wednesday, April 21, 2004 2:55 PM
> > To: [EMAIL PROTECTED]
> > Subject: Re: [ADVANCED-DOTNET] OT Continous Integration
> >
> > Curious, are you using CruiseControl or Draco?
> >
> > To some degree, Frans is right. Controlling the design of a (large)
> > relational database at the physical level can be dangerous,
> unless all
> > the individuals with the right to do so know what they are
> doing. If
> > you pull up the edits to a more logical (ERDs) or conceptual
> > (NIAM/ORM) level, then this is much better. Then, you
> create scripts
> > from the higher abstractions and push those generated
> scripts out into
> > the source control mechanism. The changed file should then trigger
> > your build. However, you might not have this choice.
> >
> > At any rate, the end product for CI is that there should be
> a master
> > DDL script as part of the build process. This script (or a
> collection
> > thereof) is what is used to create, re-create and/or populate the
> > database with data with every build.
> >
> > Also, look into what the "Database Project" in "Other Projects" in
> > VSNET can do for you as far as collecting and managing DDL scripts.
> > Here's more information than I have time to type. Now, it could be
> > that you use that, or that a repository of some sort holds
> the master
> > DDL collection.
> >
> > http://www.devx.com/assets/download/5865.pdf
> >
> > (Be careful that the scripts are executed alphabetically in
> the build,
> > although there are ways to get around this.)
> >
> > _________________________________
> > Paul Tiseo, Systems Programmer
> > Research Computing Facility
> > Mayo Clinic Jacksonville, Griffin 371
> > [EMAIL PROTECTED]
> >
> >
> >
> > > -----Original Message-----
> > > From: Unmoderated discussion of advanced .NET topics.
> > > [mailto:ADVANCED- [EMAIL PROTECTED] On Behalf Of Gary
> > > Davidson
> > > Sent: Wednesday, April 21, 2004 10:54 AM
> > > To: [EMAIL PROTECTED]
> > > Subject: [ADVANCED-DOTNET] OT Continous Integration
> > >
> > > Are there any Continous Integration shops on the list? How do you
> > > handle database changes?
> > >
> > > I am working toward having my team use continous
> integration as part
> > > of our move to AGILE programming methodologies.
> > >
> > > The one problem I can't seem to solve (i.e make everyone happy) is
> > changes
> > > to the database. Currently eveyone has their own local db and
> > distributes
> > > scripts via email and the developers don't like this and
> want to all
> > > develop on a "Central Database".
> > >
> > > I had to change from this because I was having problems
> with scripts
> > being
> > > left out of SS and when it came time to build to
> production It was a
> > > nightmare of scripts and diffs and late nights and a very
> pissed off
> > wife.
> > >
> > > I am not afraid, except for the wife :) to make an SOP
> and enforce
> > > it, I am just looking for the best solution.
> > >
> > > Very soon the source build will be automated so I want to
> solve the
> > > db part.
> > >
> > > Any ideas or help will be appreciated
> > >
> > > Gary Davidson
> > >
> > > _________________________________________________________________
> > > From must-see cities to the best beaches, plan a getaway with the
> > > Spring Travel Guide!
> http://special.msn.com/local/springtravel.armx
> > >
> > > ===================================
> > > This list is hosted by DevelopMentor�
> http://www.develop.com Some
> > > .NET courses you may be interested in:
> > >
> > > NEW! Guerrilla ASP.NET, 17 May 2004, in Los Angeles
> > > http://www.develop.com/courses/gaspdotnetls
> > >
> > > View archives and manage your subscription(s) at
> > > http://discuss.develop.com
> >
> > ===================================
> > This list is hosted by DevelopMentor� http://www.develop.com Some
> > .NET courses you may be interested in:
> >
> > NEW! Guerrilla ASP.NET, 17 May 2004, in Los Angeles
> > http://www.develop.com/courses/gaspdotnetls
> >
> > View archives and manage your subscription(s) at
> > http://discuss.develop.com
>
> ===================================
> This list is hosted by DevelopMentor� http://www.develop.com
> Some .NET courses you may be interested in:
>
> NEW! Guerrilla ASP.NET, 17 May 2004, in Los Angeles
> http://www.develop.com/courses/gaspdotnetls
>
> View archives and manage your subscription(s) at
> http://discuss.develop.com
>
>
>
>
===================================
This list is hosted by DevelopMentor� http://www.develop.com
Some .NET courses you may be interested in:
NEW! Guerrilla ASP.NET, 17 May 2004, in Los Angeles
http://www.develop.com/courses/gaspdotnetls
View archives and manage your subscription(s) at http://discuss.develop.com
