Database Configuration Control
Source code control systems are very good at managing source code, but the configuration of a large system often depends on more than just the source. A change to source code may depend on a concurrent change to the schema of an underlying database. Common changes include adding, deleting, or rearranging columns; adding indexes; applying new constraints and triggers; and so on.
Keeping track of changes to the database is somewhat harder than keeping track of changes to the source code. It's fairly easy to keep old copies of the source code, and if you also keep the scripts used to compile the source, you can reproduce the executable quickly. A truly massive project, such as a complete Linux installation, would take a very long time to compile, but such a project is usually subdivided into pieces so that it's not necessary to completely recompile everything from scratch. (It's said that it takes all night for a bank of computers to compile Windows XP from nothing but the source.)
Databases tend to be relatively heavyweight. It's usually easy to keep a test version of the database separate from the live version of the database, but keeping track of old versions is a challenge. Restoring a database to a previous version is often time-consuming.
There's no all-purpose solution to this problem. Your best bet is to maintain several databases, and a system administrator with permission to modify those databases.