Several responses to a database schema question, suggested an additional table to normalize a database for a feature that is not part of the current requirements (A UserDepartment table to allow for a many-to-many relationship between employees/users and different departments they may belong to.).Not against normalization. Seems like when it comes to database design, there is a strong push to include features that they're 'sure' someone will want in the future. Is it so difficult to add tables/fields to the database to accomodate features that there is a tendancy to over-engineer? Wouldn't they be refactored or upgraded just like the rest of the app if needed? Redoing things is never fun, but moving data from one table to a new one can be done. Just not sure where this line of thinking will end.Edit: There is so much of an aversion to this, I wonder how many projects end up not adding a feature that requires a drastic database change or are non-normalized approaches taken like adding a DepartmentID2 field instead of a new table. The need for multiple departments for an employee is a common domain problem. I just haven't noticed many database schemas that are littered with many-to-many relationships. 
Refactoring or upgrading databases to handle new features
design;database;refactoring;schema
There is an entire book written about database refactoring. Just like with code refactoring, there are standard ways to do database refactoring. The only difference is that when doing code refactoring, you don't have to consider the state of the object/code, while in databases you have to consider the data, because losing data is not good for the users (or for anyone, actually).You can read more about database refactoring here.