Truth First, or Why You Should Mostly Implement Database-First Designs
This is a really important piece for developers to read.<p>We get very used to the ability to blow away everything and start from scratch, and that's very often the right answer for build tools, but the database is fundamentally different from that, and you <i>need</i> to internalize this.<p>A database, in most cases, is the business. It's essentially a collection of all the contracts made with customers, and your mode of thinking "I can blow this away and start over" that you've learned from all sorts of build tools is completely contrary to that.<p>An infamous example of this is in Active Record migrations[1], and possibly some other migration tools.<p>> Note that we define the change that we want to happen moving forward in time. Before this migration is run, there will be no table. After, the table will exist. Active Record knows how to reverse this migration as well: if we roll this migration back, it will remove the table.<p>These are smart people, and indeed there are some <i>rare</i> cases where this is the right thing to do. But only our strongly ingrained belief that data is ephemeral would cause us to think this should be the normal behavior, that we'd want to blow away customer data to force the database to track what version X of the code thinks it should.<p>[1] <a href="http://edgeguides.rubyonrails.org/active_record_migrations.html" rel="nofollow">http://edgeguides.rubyonrails.org/active_record_migrations.h...</a>