I was reading a post from someone recently where they noted that they didn't worry to much about the architecture of the system since it wouldn't likely last very long. The poster had a comment that many systems are replaced inside of a few years.
The foundation and plumbing of a building tends to remain in place longer than the carpet, windows, and company logo.
The same goes for the databases that underlie applications. I've maintained SQL Server databases that had been in production for 15 years. But the applications stacked on top of the database went though three or four phases of re-architecture over the years, each time coinciding with a corporate merger or acquisition.
VB6 / Windows / Client Server / departmental usage
ASP.NET / Windows / corporate intranet usage
Silverlight / Windows / Web / corporate and client facing
HTML5 / web / cross-platform / public subscriptions
There were revisions to the architecture of the database over that period of time, but not so much that the initial developers wouldn't recognize the data model and ETL processes in last iteration.
Another thing to keep in mind is that the architecture of legacy databases and applications tend to become patterns and frameworks for new (more or less related) projects, so don't think that your architectural decisions exist only in the vacuum of your current project's lifecycle.
"Do not seek to follow in the footsteps of the wise. Instead, seek what they sought." - Matsuo Basho