The slightly over-simplified but useful rule of thumb when creating database schema is “normalize until it hurts, [then] denormalize until it works.” If only people didn’t skip the first step so often. Using a data modeling layer, such as Django's models, doesn't absolve the system architects from the need to create good design. It also doesn't require them to do so, since you can get away with a lot of sub-optimality with many data sets.

The real difficulty here, though, is that the trade-off between text-book ideal modeling and easy to use is difficult to judge and takes practice to develop.

This talk will walk some interesting cases of model design that I've encountered recently. I'll explain how I approached the problem and what we ended up with. These will include:

• Modeling people who might simultaneously play different roles in the system. For example, a person who was a baseball player and then became a coach — each role has different attributes attached to it.
• Modeling what appears to be a triangular dependency relationship with minimal redundancy in the data description and without needing really long query filters to access things.
• Handling date ranges (or other measured data) of different degrees of accuracy and precision.

This won't be a talk on theoretical database design. Rather, concrete examples of creating such designs and guiding the decisions by what might work best in the final Django code. Hopefully, by listening to one person's approach (mine!), people faced with similar challenges will have another possible attack method in their toolbox.