You'll be hard pressed to find any modern software department that isn't operating some variant of Agile. DBA's by comparison are stuck in the dark ages, with the kind of thinking that @RobPaller's answer contains still common place.

Modifying a database schema has never been as easy as modifying code, which is why there has been reluctance to embrace an agile approach to database development and maintenance. Now that we have the tools and techniques to operate in a similar manner to developers, we most definitely should.

  Just because it isn't easy to change schema, doesn't mean you can't and that you shouldn't.

I guess that puts my vote with your option 2 and I suspect I might find myself standing in the cold on this one!

You'll be hard pressed to find any modern software department that isn't operating some variant of Agile. DBA's by comparison are stuck in the dark ages, with the kind of thinking that @RobPaller's answer contains still common place.

Modifying a database schema has never been as easy as modifying code, which is why there has been reluctance to embrace an agile approach to database development and maintenance. Now that we have the tools and techniques to operate in a similar manner to developers, we most definitely should. Just because it isn't easy to change schema, doesn't mean you can't and that you shouldn't.

I'm not advocating a haphazard approach to database design (see comments), merely an approach which more closely mirrors that of an agile development team. If you're part of an agile project, you aren't going to have requirements for work that may (or may not) occur in the future so design for what you know is needed, not what might be.

I guess that puts my vote with your option 2 and I suspect I might find myself standing in the cold on this one!