On Monday 28 April 2008 17:35, Jeff Davis wrote: > 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-Postgre > >SQL-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. > *You* would say that, but typically movie ratings are not adjusted when a new rating comes out. For good examples of this, go back and look at 70's era movies (cowboy movies, war movies, etc...) that are G rated, but have a lot of people being shot/killed on-screen, something which would give you an automatic PG rating today. (There are similar issues with PG/R movies in the 80's, typically focused on violence and drug use, before the PG-13 rating came out). -- Robert Treat Build A Brighter LAMP :: Linux Apache {middleware} PostgreSQL
