1

This question was prompted by this answer, where I quote,"agile + ORM on a large constantly changing database is brutal".

So, how can an agile process deal with a constantly changing database? I am interested in both cases:

  1. Where the database design will stablelize, after using it a while to see how it works
  2. Where constantly changing data schemas require that the database changes often

A couple ideas I had were:

  • Use a NoSQL database
  • Creating key/value tables for different classes of data. This could create bigger tables, but might work well for data that is not inherently relational.
Community
  • 1
Michael K
  • 15,539
  • 9
  • 61
  • 93

2 Answers2

5

First, the answer lists two "problems" that have almost nothing to do with Agile or ORM.

When it's not nice and simple, the SQL will be garbage.

This means the database was poorly designed from the beginning. Many people fail to think clearly about how SQL needs to work, design poor databases, and then tweak the SQL to make it work.

ORM requires very clear thinking about objects, their relationships and navigation among the objects. Database design is the problem here, not ORM, and not Agile methods.

Our database is constantly changing. That means every couple of days someone needs to spend an hour updating the model to add a table or change datatypes that are changing (agile + ORM on a large constantly changing database is brutal).

The alternative without ORM may be weeks to change the model and fix all the SQL queries. The fact that it's only an hour every couple of days is a ringing endorsement.

All change can be "brutal". That's a fact of life. Agile is a management response (not a technical response). Change is still a lot of work. An ORM often minimizes that work. This "problem" is evidence that ORM has a nice return on investment.

So, how can an Agile process deal with a constantly changing database?

It deals with it very nicely.

Where the database design will stablelize, after using it a while to see how it works

There's no question here. This the ideal case. Change slows down.

Where constantly changing data schemas require that the database changes often.

Agile is a management response to constant change. Not a technical response. The technical response to constant change is -- well -- constant change. Sorry.

Agile management acknowledges that change is constant and plans the projects accordingly. A non-Agile management demands that all design be completed before any implementation, and all changes involve complex change-control procedures, and massive overtime to prevent project delays and lots of other bad management practices.

The technical practices are the same. Fix the model. Fix the ORM layer.

S.Lott
  • 45,264
  • 6
  • 90
  • 154
  • '...it's only an hour every couple of days is a ringing endorsement.' Not something I had thought of. – Michael K Jan 31 '11 at 15:59
  • @Michael: Look at the alternatives. Waiting weeks for DBA's to not make the requested changes. Touching dozens or hundreds of blocks of SQL. Having the stored procedures all break. – S.Lott Jan 31 '11 at 19:08
0

I think using tools that automap your database from domain entities is the way to go in many cases (e.g., Fluent NHibernate). Then you are left with creating conventions/overrides where the automapping doesn't do what you want.

Jordan
  • 101
  • 1