On Sat, 2008-04-26 at 20:33 -0400, Robert Treat wrote: > I think one of the best examples of this is the movie rating system (which I > blogged about at > http://people.planetpostgresql.org/xzilla/index.php?/archives/320-PostgreSQL-8.3-Features-Enum-Datatype.html > ) > > It's a good example of setting pre-defined values that really can leverage the > enum types custom ordering. It also showcases the idea of data definitions > that "should never change", but that do changes every half dozen years or so. > Now you can argue that since it is expected that the ratings might change in > some way every few years that an enum type is not a good choice for this, but > I feel like some type of counter-argument is that this is probably longer > than one would expect thier database software to last. :-) > Let's say you have ratings A, B, and D for 5 years, and then you add rating C between B and D. If you have a constant stream of movies that must be reviewed, then the addition of a new rating will necessarily take some fraction of the movies away from at least one of the old ratings. In that case, is an old B really equal to a new B? Similar concerns apply to other changes in ENUMs, and for that matter, they apply to the FK design, as well. I would say the *actual* rating is the combination of the rating name, and the version of the standards under which it was rated. Regards, Jeff Davis
