On Tue, 2006-11-21 at 02:51 +0000, Tom Dunstan wrote:
> Requiring a table to represent a small fixed set of
> allowable values that a column should take is broken. But because
> it's
> the least ugly solution that we've had using vanilla SQL, it's what
> we've used, and dare I suggest that because we've all done it for so
> long, we start to think that *not* doing it that way is broken.
I do support your goal of higher performance.
Putting data in tables is reasonably accepted practice, round here at
least.
I see the strong need to optimise the case where people want/need to
follow the SQL standard and have defined their databases that way. There
is also the need to support DELETE RESTRICT functionality from the
referenced to the referencing table, as a protection against data
quality problems. A link between two tables is important - otherwise we
introduce another DBA task and the possibility of error that results.
If there is a body of opinion behind enums, then thats good. The MySQL
way is not something to be ignored and that is a good argument for
inclusion. I've got no problem with multiple ways of doing things.
In the long run, as currently envisaged, enums don't do all that I would
like. I see the need to performance tune Referential Integrity more
directly.
-- Simon Riggs EnterpriseDB http://www.enterprisedb.com
