Description

How would you model players, umpires and coaches in baseball data when
the same person can switch roles over the course of their life? How
about servers in racks with power boards attached (and cords running
across the room to remote boards)? Come along to see one approach to
create minimal and well- performing models for such real-life
situations.

Abstract

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.