That premature optimization means you shouldn't optimize at all. I've seen more horrendously bad databases because no one wanted to consider performance (critical to any database system) in design as that was premature optimization than any other database design issue . Rubbish, there are known performance killers, stop using them as your first choice.
Another myth, it's too hard to refactor the database. No but you have to consider how to do refactoring in the design phase to do it effectively. And BTW, the longer you wait to fix that annoying design-based performance issue, the harder it's going to be to fix.
Another bad myth, database design should reflect OOP principles. No, databases are designed to work with sets not OOP principles. Some OOP things will cause horrible performance problems and others are just pain silly in database terms.
Finally, you should enforce data integrity in the application. Databases are going to last past the application and would lose the rules when the application is replaced, mulitple applications are going to access them and there will often be the need to run direct queries to fix things that do not go through the application. I have never seen a database that refuses to enforce data integrity in the datbase that has good data.