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
