I was reading some posts about the moment the database design should happen while "agile" developping a new application.
Firstly I was wondering how many applications are not using a database to store their state. But this is not the real question here. It is only related to the rest [blink/].
The discussion I have read pointed out that the development started just after the database design was done. For me this means that all the cards for the domain model where drawn (and probably some more interaction diagrams). So at this early point you have all your domain model object defined. Isn't this bduf? What is the relation with agile (iterative) development?
Now the real question bugging my head: isn't supposed to have the domain model evolve together with the rest of the system? While doing iterative development I expect to have some changes into my model. These changes will be reflected in the database on which I have already spent some time before. Than why spend doing the database design in a separate iteration?
My opinion is that database design should be done the same way the development is done: are you doing waterfall than design the database the same way. Are you doing iterative development? Than do the database development the same way.
2 comments:
It depends on the completeness of the requirements. If the requirements are complete enough then the database design should not have undergo major refactoring as the software/modules evolve down the road.
But in reality, most of the time, is not like this :P
I prefer solution like this (using Hibernate):
1. Design your program as usual (whatever it means :), determine objects that need persistence and annotate them (XDoclet or EJB3 annotations). Utilize hbm2ddl.auto feature of Hibernate so for most of the development time you don't need to bother with the database.
2. When the system is almost ready (or when you have to do so) fine tune the database schema by adding indices, constrains, etc.
Post a Comment