Win a copy of Programmer's Guide to Java SE 8 Oracle Certified Associate (OCA) this week in the OCAJP forum!
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

Database Agility

 
Paul Croarkin
Ranch Hand
Posts: 106
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I've seen many projects where the database schema is way over engineered up front because people are afraid that the schema will be set in stone once they reach production. Of course, something is always missed anyway and lots of columns and tables exist in the schema that are never used. This leads to awful things like adding a second copy of table that is modified and leaving the original table in place but not used (or still used - who can tell without wasting time doing deep analysis?).

We've gotten around this to a good extent by having each developer point at a local database and then have the automated build process (CruiseControl) point at an integration database. The build process drops and re-creates the database for each build.

When moving to a higher environment, DBAs need to get involved. They version control scripts that control each modification to the database. This step is a little more painful because the DBAs will cannot just drop the schema and start from scratch.

Do you have any suggestions for a better solution?
 
Ilja Preuss
author
Sheriff
Posts: 14112
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
You might want to spend some time at http://www.agiledata.org/ ...
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic