Which is more important: The design of the database? Or the design of the application code?
There is a lot of information out there about reusable code (from Carl Franklin at dnrtv.com, CSLA.net, et. al.), but I don't see too much information about Database Design and its impact on the life of an application (particularly how bad design decisions early on affect the application later in its 'life'.
Both
Great code can be ruined by a horrible db design and a great db design can be ruined by horrible code.
Both are important of course, it's a symbiotic relationship.
But if your DB is jacked, no amount of good code can make your app shine.
However, if your DB is really good, then good code can make it even better (but bad code can still ruin it).
Look at it this way
Ergo it is important to get the database as stable as possible as early as possible
If you are careless with either one you are doomed.
I can see I'm going to be swimming upstream, but I'm pretty strongly biased toward software being the answer to your question.
While your software can adapt to a weak schema, there's not much your database can help you with if your software is disfunctional. I've had a couple cases where I've been able to take a popular front-end application and totally rebuild the database without serious disruption, because the users don't see the database directly. (Which won't be true if the software is crap.)
So I'd say pay attention to what's closest to the user first.
You DB design is most important.
I'm a coder, and I prefer code, but ... if you screw up the DB design, your code will be a nightmare. Your code won't have a chance!
Even when you try to refactor the DB design, you will have so much work around code, that fixing it all will be overwhelming.
This isn't a preference or even a close one, it's very much leaning toward the DB design being most important.
EDIT: Even if you were to have key-value pair tables where everything got dumped into it, that would still be a DB design based on business requirements.