It's always those developers throwing things over the wall, or the feature requests from product managers - never giving the time to design it right the first time. There may be some thread of truth to those statements, but if we take advantage of those new features, bug fixes, maint windows, we could do a lot for ourselves in terms of performance tuning.
Here's a couple examples to get you started thinking:
A new feature:
- Does it require new tables?
- Have we thought about partitioning should the data in those tables scale up?
- Have we thought about primary keys and which columns should or should not be included given usage and future modifications?
- Have we thought about foreign keys and associated indexes?
- Have we thought about normalization?
- Is the new feature heavy read or heavy write?
- Should we be considering additional data files and/or data stores?
- Are there certain types of indexes that might be more prudent in the long term?
- How does this fit in with our HA / disaster recovery scenarios?
- Does the new feature have any long term reporting benefits?
- Are changes easily monitored?
- Is the data easily transformed to dimensions / facts?
- Should there be some archival process?
If we want to make our lives easier, we need to be the ones asking those questions, and in such a way that helps the development team see the benefit in making those decisions now, and not a year from now when we've added a new customer with 500,000 new transactions a day...
As DBA's we need to strive to get on the front end of the development cycles to make it as easy as possible for our development teams to take advantage of features and designs that will allow scalability and manageability with our databases - whatever those databases might be.
If you're not doing that, then in my opinion, you might as well outsource your database administration to some company that just gonna monitor alerts and backup your data....