Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    text
    copied!<p>For me, this is a question with a "theoretical" answer and a "real world" answer.</p> <p>In theory, you add a column as and when you need it, and you refactor your database as you go, because that's agile.</p> <p>In the real world, your DBAs will kill you if they have to rebuild your test data every five minutes because you've changed the schema again. And in a smaller project, you'll get personally sick of having to spend half your time maintaining an unstable database.</p> <p>As skaffman alluded to in a comment: database maintenance is generally more expensive than code maintenance. This is doubly true for rollout: you can roll an entire new application without a hitch, but try planning a live database upgrade without breaking your data.</p> <p>It's a difficult discussion, because agile purists will insist that everything should be done "just in time." But, as in most things agile, the reality is that <em>someone</em> needs to be looking ahead of the next release. Priorities do change, but if there's not at least a vague idea of what the product will look like in 6 months then you've got bigger problems than development methodology...</p> <p>The role of an architect (or tech lead, or chief DBA, or whatever flavour you have) is to be looking ahead those few months and planning for what you are 90% sure is coming, and part of that will be defining the data you're going to need and where it's likely to live.</p> <p>So, perhaps instead of adding a column at a time, add a table at a time. Find the balance that suits your project and your development process, without doubling your workload.</p>
 

Querying!

 
Guidance

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload