[agronomov]

Nice article, but I wonder what author would say about working with ORMs. When objects represent database tables it's not as easy to extract attributes into objects. Every extract, rename or move is a database migration, when you probably want to keep the old columns around for a bit in case things go wrong. With author's philosophy in mind it feels it's quite easy to bury yourself in that process instead of adding direct business value.

[pbw]

I really have not worked with databases a ton. But I do a think a huge thing I didn't address in the article is how readily are you even able to make changes?

I'm really talking about a system where you free to change things. Once stuff is exposed to the outside world you might relinquish your ability to keep factoring and factoring. Although that's a reason to only expose an API and not your actually object structure.

I'm not sure how this all related to databases, but I suspect in many cases there you simply can't change existing things, too much would break. So yeah I think that's a different ball game to some degree.

[tchaffee]

That's a good question.

With database normalization you do end up with more tables that have less columns anyway.

But the ORM boundary has always been problematic and normalization won't always get you down to seven columns, so the question remains.