I came across a blog post about the Rules of Database App Aging today. I’m having another look at my database assumptions at the moment, and the three rules that Peter Hawkins lays out seem solid:
1. All Fields Become Optional.
2. All Relationships Become Many-to-Many.
3. Chatter Always Expands.

The article doesn’t make any suggestions for how to work with these problems, but clearly a lot of flexibility is a plus. In fact, it seems that trying to build in more flexibility than you’ll necessarily need is a good approach, but that seems to constitute premature optimization…

I’m trying to figure out how those rules fit in with good normalization practices and the need to have decent database performance.

(And yes, this means that I’m thinking about starting work on sfmagic.org again in the near future.)

This entry was posted on Monday, January 19th, 2009 at 18:58 19 Jan 2009 and is filed under Blog. You can follow any responses to this entry through the RSS 2.0 feed. You can skip to the end and leave a response. Pinging is currently not allowed.

2 Responses to “Rules of Database App Aging”

1. Kevin Teljeur Says:
   21 Jan 2009 at 07:14

   Are you building that in PHP? If you want any code from my mini-framework (well, a set of utilities, more like) then let me know. It’s designed to be database-friendly – you build your objects for your needs and let it worry about the DB stuff.

   Sean apparently has some interesting stuff that takes care of the UI too, as well as abstracting out the DB stuff.

2. Peter Harkins Says:
   21 Jan 2009 at 10:32

   I didn’t have any suggestions for what to do because I don’t see them as problems. I try to make a clean, normalized schema and sometimes the real world comes along and changes requirements with weird exceptions and new options.

Leave a Reply

Name (required)

Mail (will not be published) (required)

Website