On Fri, Sep 26, 2008 at 3:10 PM, David Chelimsky <[EMAIL PROTECTED]>wrote:
> > Now sometimes there will be some up-front modeling discussions and you > may have a sense that a model needs a specific set of fields just > because that's what the customer says. In those cases, I'd recommend > trying to find something about the object's behaviour to rationalize > the presence of those fields. > I think I know what you mean, and I would reply with two points, one agile, and one not so agile: 1) In a test-driven environment, you don't write code until you write a failing test. Now, unless you mean to spread your table definition across multiple migrations, that means you would have to write a spec for Demographics Reports before you could create your table. By testing attributes directly, you can indeed write a failing spec, then make it pass by writing a migration. It's not a huge deal, because you could indeed write multiple migrations as you define clients of the data. 2) The second is more important, however, and has to do with the non-agile nature of databases. Put simply, you can't change database content like you can change code. The example I used to use (probably outdated now) is fax number. If you're writing a customer relationship management system, you might want to store customer fax numbers _even if you have no use for them_. The reason is simply that if you _do_ need them later, you can't go back and get them. In other words, databases can have a prophecy requirement that ever-malleable code does not. All that said, I think your developer's conversation with the customer is very apt. In many if not most cases, if there's no output for the data, there's no need for its input. But not always. ///ark
_______________________________________________ rspec-users mailing list rspec-users@rubyforge.org http://rubyforge.org/mailman/listinfo/rspec-users
